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: base-files: Does not permit the use of symlinks in /etc/profile.d/


On Sun, September 18, 2005 10:14 pm, Corinna Vinschen wrote:
> On Sep 18 11:12, John Morrison wrote:
>> On Sat, September 17, 2005 2:35 pm, Corinna Vinschen wrote:
>> > I'm wondering if base-files can't check if /etc/profile has been
>> changed,
>> > for instance, using md5sum.  Then it could overwrite the file if it's
>> > still
>> > the original version, or, if it has been changed, move it away to, for
>> > instance, /etc/profile.SAV or something.
>>
>> The preremove part of base-files could be modified to rename any of the
>> files that have been modified (if they haven't then they are deleted
>> ready
>> for the post-install routine to install new versions) - although I don't
>> know if it's desirable behaviour.  I'm not sure if I'd be terribly happy
>> to have cygwin just rename my customisations out of the way, would be
>> *highly* confusing the first (at least!) time it happened...
>
> That shouldn't be the rule, maybe.  But our current layoput has the
> obvious disadvantage that important changes to default config files
> in a lot of cases don't make it into the users system in some way.

Humm, playing devils advocate for a minute - but if a user is happy with
the system they've got (perhaps by tweaking files themselves) - is it the
systems job to force them to update?

> In rpm, there's a mechanism which allows the package maintainer to
> define the changes as so important, that rpm moves the old file out
> of the way (renaimg it to foo.oldrpm or something like that),
> installs the new file and sends a mail to root about this.

I don't think we can send emails - lots of people (myself included) don't
have email setup to work under cygwin.

Personally, I like the Debian way of saying that somethings changed and
would the user like to view differences, ignore, merge, overwrite etc (or
whatever's appropriate).  But am unsure as to how to get this to work when
it'd have to be negotiated between setup.exe and the post-install
scripts...

How about using the return value to flag setup.  Setup could then, for
example, display a special 'log' file - or, if the file exists perhaps
/etc/profile could cat it then delete it?

> Something like this is definitely missing in our technique, that's
> why I was trying to start a discussion about this.

Sorry, think my reply came across a bit grumpy - not intended!

> OTOH, I guess there are a lots of people not changing the files in
> /etc, using always the default files.  In these cases, a mechanism
> which allows to recognize these files as being the genuin one would
> be helpful, wouldn't it?  It would allow to simply overwrite them,
> so the users would get the latest changes without hassle.

If the file hasn't been modified it is deleted by the pre-remove script,
the copy in /etc/defaults is overwritten by setup.exe and the post-install
script copies missing files.  At least that's how base-files works.

I did have a conversation, oh a year or more ago now, with cfg to see if
we could manage /etc/defaults automatically with one central script, but
we couldn't work out how to get it to work consistently.

*grin* at this rate how long do you think before cygwin counts as a
complete 'distro'?

J.


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