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.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
On Sep 19 09:02, John Morrison wrote: On Sun, September 18, 2005 10:14 pm, Corinna Vinschen wrote: 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? The problem is that the user might be happy, but at one time the system is suddenly broken for no apparent reason to the user. The actual reason was that a package A relies on a feature introduced in a default config file in package B. Come to think of it, maybe this is something which never should happen. If a package *relies* on something in a default config file, which is by definition intended to be overwritable by the user, then that package is seriously broken. 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. [...] 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? What about this: Setup creates a subdir /var/log/setup. Package preremove and postinstall scripts, which have encountered a situation which requires them to inform the user about an important change can write a file /var/log/setup/package.info. When setup has finished update, it searches this directory and if files are available informs the user that package foo has something to talk about. Do you want to read [Y/N]? If yes, Setup opens a dialog with just a scrollable field which contains the contents of the info file. Afterwards it renames or removes the info file. Sorry, think my reply came across a bit grumpy - not intended! No worries. *grin* at this rate how long do you think before cygwin counts as a complete 'distro'? Heh, it's a complete distro to me ;-) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
On Sat, September 17, 2005 2:35 pm, Corinna Vinschen wrote:
On Sep 17 07:19, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Max Bowsher on 9/16/2005 4:27 PM:
The current /etc/profile does not permit the use of symlinks in
/etc/profile.d/ - it ignores them.
Unfortunately, even if this was fixed in the package, existing
installs
wouldn't get fixed, because /etc/profile is handled via /etc/defaults
:-(
/me gives up on finding a way for /sbin/alternatives to influence
$MANPATH.
Here's my idea - add a /etc/profile/symlinkhandler.sh that detects
whether
/etc/profile has been patched yet, and if not, source all the symlinks
in
/etc/profile. Now which package should provide that (alternatives vs.
base-files vs. something else), I'm not sure. But you are also right
that
base-files should be patched to source links to regular files as well as
regular files. One idea is to change that the appropriate line in
/etc/default/etc/profile from 'if [ -f ${f} ]' to 'if [ ! -d $f/ ]'.
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...
J.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
On Sat, September 17, 2005 5:33 pm, Max Bowsher wrote: John Morrison replied to me privately (accidentally, I presume). Yes, it was - sorry Max. I'm forwarding the message to cygwin-apps@ to maintain threading: Thanks - I wondered by it didn't appear on the list before I logged off! J.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
On Sun, September 18, 2005 1:14 am, Max Bowsher wrote:
Eric Blake wrote:
Sorry, didn't realise. If I change the line
/bin/find /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh'
to be
/bin/find -L /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh'
would that fix things? (The -L tells find to follow the link and make
decisions based on the actual file AFAICT).
Would find then apply the -iname tests to the link destination too,
then?
True - once you turn on -L, all the tests are applied to the
destination.
Also, the existing code is redundant (find has already proven the
file exists and is regular, so the [ -f ${f} ] is unneeded), and
buggy,
since it tries to source non-files named *.zsh, as though it were
written:
\( -type f -a -iname '*.sh' \) -o -iname '*.zsh'
So how about this:
if [ -d /etc/profile.d ]; then
for f in `/bin/find /etc/profile.d -xtype f \( -iname '*.sh' -o
-iname '*.zsh' \) | LC_ALL=C sort` do
. $f
done
fi
That would be a potential confusion. How about using \( -type f -o
-type
l
\) ?
-type l won't cut it, because it gets false positives on a symlink to a
directory.
This makes me think: Why are we trying so incredibly hard to detect
directories?
Humm, hold over from the first days of this code I would imagine.
If someone does someone so incredibly bizarre as creating a directory
named
'/etc/profile.d/foobar.sh/' (or .zsh or .csh), why not let them suffer the
error message?
Not a problem really, so, do I go with:
if [ -d /etc/profile.d ]; then
for f in `/bin/find /etc/profile.d -xtype f \( -iname '*.sh' -o
-iname '*.zsh' \) | LC_ALL=C sort` do
. $f
done
fi
do we even need the outer if?
J.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
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. 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. Something like this is definitely missing in our technique, that's why I was trying to start a discussion about this. 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Max Bowsher on 9/16/2005 4:27 PM:
The current /etc/profile does not permit the use of symlinks in
/etc/profile.d/ - it ignores them.
Unfortunately, even if this was fixed in the package, existing installs
wouldn't get fixed, because /etc/profile is handled via /etc/defaults :-(
/me gives up on finding a way for /sbin/alternatives to influence $MANPATH.
Here's my idea - add a /etc/profile/symlinkhandler.sh that detects whether
/etc/profile has been patched yet, and if not, source all the symlinks in
/etc/profile. Now which package should provide that (alternatives vs.
base-files vs. something else), I'm not sure. But you are also right that
base-files should be patched to source links to regular files as well as
regular files. One idea is to change that the appropriate line in
/etc/default/etc/profile from 'if [ -f ${f} ]' to 'if [ ! -d $f/ ]'.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDLBfe84KuGfSFAYARAq/OAJ0ePSND3+dL3y2rfn/chQpUJMlowwCbBHcG
MHov4KjEgR1bUhz798rzyWQ=
=TS1v
-END PGP SIGNATURE-
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 9/17/2005 7:19 AM: Here's my idea - add a /etc/profile/symlinkhandler.sh that detects whether /etc/profile has been patched yet, and if not, source all the symlinks in /etc/profile. And after more thought, one easy way for symlinkhandler to realize if symlinks have been sourced, which works since the profile.d scripts are sourced in alphabetical order: /etc/profile.d/symlinkhandler1.sh - /etc/profile.d/symlinkhandler1 /etc/profile.d/symlinkhandler1: # set to let symlinkhandler2.sh know that symlinkhandler1.sh was called symlinks_in_profile_d_have_been_sourced=yes /etc/profile.d/symlinkhandler2.sh: if [ x$symlinks_in_profile_d_have_been_sourced != xyes ] ; then # only regular files have been sourced so far; source the symlinks for f in `find /etc/profile.d -type l -xtype f -name '*.sh'` ; do . $f done fi # unset to avoid polluting the shell variable namespace unset symlinks_in_profile_d_have_been_sourced - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDLBt+84KuGfSFAYARAt4zAKCMSISRkvbGtOuaMU7OHVgHysY7nQCeM5h3 j37zXYFTYOl1GN/gAAvnQm0= =tLOq -END PGP SIGNATURE-
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
On Sep 17 07:19, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Max Bowsher on 9/16/2005 4:27 PM:
The current /etc/profile does not permit the use of symlinks in
/etc/profile.d/ - it ignores them.
Unfortunately, even if this was fixed in the package, existing installs
wouldn't get fixed, because /etc/profile is handled via /etc/defaults :-(
/me gives up on finding a way for /sbin/alternatives to influence $MANPATH.
Here's my idea - add a /etc/profile/symlinkhandler.sh that detects whether
/etc/profile has been patched yet, and if not, source all the symlinks in
/etc/profile. Now which package should provide that (alternatives vs.
base-files vs. something else), I'm not sure. But you are also right that
base-files should be patched to source links to regular files as well as
regular files. One idea is to change that the appropriate line in
/etc/default/etc/profile from 'if [ -f ${f} ]' to 'if [ ! -d $f/ ]'.
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.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat, Inc.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
John Morrison replied to me privately (accidentally, I presume). I'm forwarding the message to cygwin-apps@ to maintain threading: Original Message below: --- Hi Max, On Fri, September 16, 2005 11:27 pm, Max Bowsher wrote: The current /etc/profile does not permit the use of symlinks in /etc/profile.d/ - it ignores them. Sorry, didn't realise. If I change the line /bin/find /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh' to be /bin/find -L /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh' would that fix things? (The -L tells find to follow the link and make decisions based on the actual file AFAICT). Unfortunately, even if this was fixed in the package, existing installs wouldn't get fixed, because /etc/profile is handled via /etc/defaults :-( What's wrong with /etc/defaults? This sort of update is precisely what it's supposed to handle. The only time people won't get upgraded is if they've manually edited their /etc/profile (or they have a copy which existed before /etc/defaults came into existence). These folks have been told to upgrade and where it's better to place their modifications, surely we've given them enough time by now ;) J. PS, off this thread, since you are maintaining Apache2 atm, could you let me know if you've ever taken a look at the php module? I'd like to get phpBB working, but couldn't get the php module to compile correctly. No worries if it's not on your agenda ;)
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
John Morrison wrote: Hi Max, On Fri, September 16, 2005 11:27 pm, Max Bowsher wrote: The current /etc/profile does not permit the use of symlinks in /etc/profile.d/ - it ignores them. Sorry, didn't realise. If I change the line /bin/find /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh' to be /bin/find -L /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh' would that fix things? (The -L tells find to follow the link and make decisions based on the actual file AFAICT). Would find then apply the -iname tests to the link destination too, then? That would be a potential confusion. How about using \( -type f -o -type l \) ? Unfortunately, even if this was fixed in the package, existing installs wouldn't get fixed, because /etc/profile is handled via /etc/defaults :-( What's wrong with /etc/defaults? This sort of update is precisely what it's supposed to handle. The only time people won't get upgraded is if they've manually edited their /etc/profile (or they have a copy which existed before /etc/defaults came into existence). These folks have been told to upgrade and where it's better to place their modifications, surely we've given them enough time by now ;) Oops - you're completely right! It never occurred to me that there was some /etc/defaults processing done at preremove time. PS, off this thread, since you are maintaining Apache2 atm, could you let me know if you've ever taken a look at the php module? I'd like to get phpBB working, but couldn't get the php module to compile correctly. No worries if it's not on your agenda ;) I don't have much personal use for PHP, so I've not tried to compile it. I'm happy to discuss problems though - start a new thread. Max.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
Sorry, didn't realise. If I change the line
/bin/find /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh'
to be
/bin/find -L /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh'
would that fix things? (The -L tells find to follow the link and make
decisions based on the actual file AFAICT).
Would find then apply the -iname tests to the link destination too, then?
True - once you turn on -L, all the tests are applied to the destination.
Also, the existing code is redundant (find has already proven the
file exists and is regular, so the [ -f ${f} ] is unneeded), and buggy,
since it tries to source non-files named *.zsh, as though it were written:
\( -type f -a -iname '*.sh' \) -o -iname '*.zsh'
So how about this:
if [ -d /etc/profile.d ]; then
for f in `/bin/find /etc/profile.d -xtype f \( -iname '*.sh' -o -iname
'*.zsh' \) | LC_ALL=C sort`
do
. $f
done
fi
That would be a potential confusion. How about using \( -type f -o -type l
\) ?
-type l won't cut it, because it gets false positives on a symlink to a
directory.
--
Eric Blake
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
Eric Blake wrote:
Sorry, didn't realise. If I change the line
/bin/find /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh'
to be
/bin/find -L /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh'
would that fix things? (The -L tells find to follow the link and make
decisions based on the actual file AFAICT).
Would find then apply the -iname tests to the link destination too, then?
True - once you turn on -L, all the tests are applied to the destination.
Also, the existing code is redundant (find has already proven the
file exists and is regular, so the [ -f ${f} ] is unneeded), and buggy,
since it tries to source non-files named *.zsh, as though it were written:
\( -type f -a -iname '*.sh' \) -o -iname '*.zsh'
So how about this:
if [ -d /etc/profile.d ]; then
for f in `/bin/find /etc/profile.d -xtype f \( -iname '*.sh' -o
-iname '*.zsh' \) | LC_ALL=C sort` do
. $f
done
fi
That would be a potential confusion. How about using \( -type f -o -type
l
\) ?
-type l won't cut it, because it gets false positives on a symlink to a
directory.
This makes me think: Why are we trying so incredibly hard to detect
directories?
If someone does someone so incredibly bizarre as creating a directory named
'/etc/profile.d/foobar.sh/' (or .zsh or .csh), why not let them suffer the
error message?
Max.
