This is the mail archive of the
mailing list for the Cygwin project.
Re: cygport: patches welcome?
- From: Andrew Schulman <schulman dot andrew at epamail dot epa dot gov>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 13 Jul 2007 05:58:11 -0400
- Subject: Re: cygport: patches welcome?
- References: <email@example.com> <4696F3CE.firstname.lastname@example.org> <4696F3CE.9060304-PGZyUNKar/Q@public.gmane.org> <20070713080632.GL6851@calimero.vinschen.de>
> [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
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
cp /etc/defaults/etc/file /etc
(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
in their cygport scripts, and cygport will automatically bake the right
logic into their packages.