> [Grr, I forgot to redirect this Mail. This should have gone > to the cygwin-apps list, actually]
OK, but in that case the cygport README needs to be corrected, because it says questions should go to the cygwin list. > > > (2) Smarter update of config files. In cygport's make_etc_defaults > > > function, we have a golden opportunity to fix a problem that's persisted > > > for > > > a long time in Cygwin: when a package's default config file (typically in > > > /etc) is updated, we don't currently have a standard way of automatically > > > and safely installing the new version, because just copying it into /etc > > > would destroy any of the user's existing customizations. Our current best > > > practice is to put > > > > > > [ -f /etc/file ] || cp /etc/defaults/etc/file /etc > > > > But when coupled with preremove scripts, this is the right approach. > > Provided, of course, that the pre-remove does: > > > > cmp -s /etc/file /etc/defaults/etc/file && rm /etc/file > > > > or similar, which removes the file only if it is unmodified, so that the > > followon postinstall will only install the file if the user never touched > > it prior to the upgrade. Yes, this seems like a good approach, and cygport could easily do it, too. > I'm still not sure how to handle situations where the default config > file in /etc/defaults/etc has changed between releases, but the user has > also changed the copied config file in /etc. We have no mechanism and > no standarized way to handle this so far. When you say "handle", I think you mean notify the user, rather than try to merge the changes. Correct? > It looks like the postinstall script would have to create a copy of the > file within /etc/defaults/etc first. This allows the postinstall script > in subsequent releases to recognize the fact that the config file has > changed. I think that this won't be necessary if we use Dave's suggestion to remove config files in preremove scripts if they haven't changed. Then all the postinstall script has to do is if [ -f /etc/file ] ; then exit 32 else cp /etc/defaults/etc/file /etc fi (but with smarter exit handling). > We could create a similar naming convention as rpm (.cygnew, .cygorig) > and then we just need a way that setup notifies the user. > > Two ideas come to mind. > > - A postinstall script which has created a backup file returns a > standarized return code (42 for instance). Setup uses this return > code to create a "backup files have been created by the following > packages" list. > > - We only allow this mechanism for the /etc directory. After the > postinstall scripts have finished, setup searches /etc and creates > a list of backup files which it presents to the user. > > Does that sound ok? Any other ideas? Debian asks the user what they want to do when it wants to update a config file and finds that it's been modified. But there's no mechanism for that right now in setup, so we probably don't want to rely on adding it. How about both: postinstall scripts that weren't able to update a config file because it was modified exit with signal 32 (or whatever; I suggest a power of 2 so we can use bitmasks). If any postinstall scripts exit with 32, then setup searches for .cygnew files in /etc and presents the list to the user. A side effect of this would be that each time a config file can't be updated, setup would present the entire list of .cygnew files to the user-- even if they were there from a previous installation, so the user had already been notified about them before. I think this would probably be okay, maybe even good, as long as the user didn't get a new nag screen *every* time they installed any new package-- only when a config file couldn't be updated. Anyway, no matter how we decide to handle it, it's clear that the logic should go into cygport's make_etc_defaults function, so that packagers can continue to just call make_etc_defaults /etc/file in their cygport scripts, and cygport will automatically bake the right logic into their packages. Andrew.
