This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygport: patches welcome?


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
> else
>   cp /etc/defaults/etc/file /etc
> fi
> 
> (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.

I agree.

> 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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]