This is the mail archive of the
mailing list for the Cygwin project.
Re: cygport: patches welcome?
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 13 Jul 2007 13:06:53 +0200
- 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> <email@example.com>
- Reply-to: cygwin-apps at cygwin dot com
On Jul 13 05:58, Andrew Schulman wrote:
> > [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.
Actually I grabbed this thread to talk about a setup issue. It's
not so much a cygport problem.
> > 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?
Notifying the user and creating .rpmnew/.rpmorig (s/rpm/cyg) files.
> > 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
> cp /etc/defaults/etc/file /etc
> (but with smarter exit handling).
Hmm, yes, that doesn't sound bad.
> 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.
That would be good but it's the second step. The first step is to
figure out how we do it in setup and postinstall/preremove scripts,
if at all.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com