Re: /usr/local/bin in $PATH in system scripts?
On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote: Sorry, I have no idea what ubuntu policy is. But good defensive scripting practice includes setting your $PATH to something safe. A good script should always not trust the environment it was handed along with many other things that people don't always do. I have to disagree. The environment is precisely the tool available to users to change the behavior of your script externally. It's not nice to stomp on user preferences. The original problem is user error. Installing an upgraded perl in /usr/local without installing all of the needed perl libraries or removing /usr/local/bin from the default system PATH is incorrect usage. Don't break features to avoid user error, please. -Forest signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
Fergal Daly wrote:
On 10/05/07, Forest Bond [EMAIL PROTECTED] wrote:
On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote:
Sorry, I have no idea what ubuntu policy is. But good defensive
scripting practice includes setting your $PATH to something safe. A
good script should always not trust the environment it was handed along
with many other things that people don't always do.
I have to disagree. The environment is precisely the tool available to
users to
change the behavior of your script externally. It's not nice to stomp on
user
preferences.
The original problem is user error. Installing an upgraded perl in
/usr/local
without installing all of the needed perl libraries or removing
/usr/local/bin
from the default system PATH is incorrect usage. Don't break features to
avoid
user error, please.
You have 2 assertions in one sentence, I'm splitting them up.
1 - Installing an upgraded perl in /usr/local without installing all
of the needed perl libraries is incorrect usage
This directly contradicts the debian policy I quoted which essentially
says that the contents of /usr/local should have no impact on whether
your system works or not. I know Debian is not Ubuntu but in the
absence of Ubuntu policy docs, I'm assuming that the Debian policy is
a sane starting point.
Yes, but that's not actually what it states (repasted):
However, because /usr/local and its contents are for exclusive use of
the local administrator, a package must not rely on the presence or
absence of files or directories in /usr/local for normal operation.
It is not relying on the presence or absence of any files. It is relying
on your PATH to give it a good perl. That /perl/ is relying on the
presence or absence of various files. I don't think that this paragraph
was ever meant to be applied to such indirect reliance.
You are also implying that everything in /usr/bin that start with
#! /usr/bin/{perl,python,...}
is wrong and should actually start with
#! {perl,python,...}
That doesn't work. #! requires a path.
--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
signature.asc
Description: OpenPGP digital signature
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On 10/05/07, Micah Cowan [EMAIL PROTECTED] wrote:
Fergal Daly wrote:
On 10/05/07, Forest Bond [EMAIL PROTECTED] wrote:
On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote:
Sorry, I have no idea what ubuntu policy is. But good defensive
scripting practice includes setting your $PATH to something safe. A
good script should always not trust the environment it was handed along
with many other things that people don't always do.
I have to disagree. The environment is precisely the tool available to
users to
change the behavior of your script externally. It's not nice to stomp on
user
preferences.
The original problem is user error. Installing an upgraded perl in
/usr/local
without installing all of the needed perl libraries or removing
/usr/local/bin
from the default system PATH is incorrect usage. Don't break features to
avoid
user error, please.
You have 2 assertions in one sentence, I'm splitting them up.
1 - Installing an upgraded perl in /usr/local without installing all
of the needed perl libraries is incorrect usage
This directly contradicts the debian policy I quoted which essentially
says that the contents of /usr/local should have no impact on whether
your system works or not. I know Debian is not Ubuntu but in the
absence of Ubuntu policy docs, I'm assuming that the Debian policy is
a sane starting point.
Yes, but that's not actually what it states (repasted):
However, because /usr/local and its contents are for exclusive use of
the local administrator, a package must not rely on the presence or
absence of files or directories in /usr/local for normal operation.
It is not relying on the presence or absence of any files. It is relying
on your PATH to give it a good perl. That /perl/ is relying on the
presence or absence of various files. I don't think that this paragraph
was ever meant to be applied to such indirect reliance.
It's relying on the absence of perl or if perl is there it's relying
on the presence of /usr/local/lib/perl/Foo/Bar.pm . Also, it's not
_my_ PATH, it's the path that is explicitly set by some system
scripts.
Can you give me a definition of good perl that isn't equivalent to
exactly compatible with /usr/bin/perl? Where compatible means
feature for feature _and_ bug for bug because I as a sysadmin have no
idea what the next apt-get upgrade will depend on.
If /usr/local/bin/X has to be exactly the same as /usr/bin/X, what's the point?
Please also address how I'm supposed to keep the modules in this
version of perl in sync with the versions in /usr/lib without help
from apt (I'm not saying it can't be done but your interpretation
imposes this extra work on me). How about when I install a package
that pulls in a new perl-Blah.deb as a dependency? I should manually
track and replicate these changes?
A far more useful interpretation is the contents /usr/local should
have no effect on the system's normal operation. What are the
down-sides of this interpretation?
You are also implying that everything in /usr/bin that start with
#! /usr/bin/{perl,python,...}
is wrong and should actually start with
#! {perl,python,...}
That doesn't work. #! requires a path.
Sorry
#! /usr/bin/env {perl,python,...}
The point being that if you believe that all system scripts should
respect each user's path then you should be appalled at the number of
things in /usr/bin/ that completely ignore it,
F
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On Thu, May 10, 2007 at 08:59:19AM -0700, Micah Cowan wrote:
Fergal Daly wrote:
You are also implying that everything in /usr/bin that start with
#! /usr/bin/{perl,python,...}
is wrong and should actually start with
#! {perl,python,...}
That doesn't work. #! requires a path.
For the sake of discussion, I think
#!/usr/bin/env perl
will pick up $PATH and is a valid #! line. I also believe this is widely
used.
Ming
2007.05.10
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On Thu, May 10, 2007 at 08:33:41PM -0700, Micah Cowan wrote: Ming Hua wrote: For the sake of discussion, I think #!/usr/bin/env perl will pick up $PATH and is a valid #! line. I also believe this is widely used. Yes, it will. But isn't that a somewhat silly suggestion considering the context? If /usr/bin/perl were bad then /usr/bin/env would be just as bad, it seems to me... That's not the point. Fergal's argument is, if you think scripts honoring the $PATH variable and use the binaries /usr/local/bin/ is a feature because it respects the user preference, you should also think using #!/usr/bin/env perl instead of #!/usr/bin/perl a feature as well, for the same reason. And I think it's a valid argument. Debian guarantees /usr/bin/perl and /usr/bin/env will work. I think the focus of this discussion is what happens if we have a bad /usr/local/bin/perl, not a bad /usr/bin/perl. Ming 2007.05.10 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On 09/05/07, Soren Hansen [EMAIL PROTECTED] wrote: On Wed, May 09, 2007 at 10:43:29AM +0200, Oliver Grawert wrote: However, because /usr/local and its contents are for exclusive use of the local administrator, a package must not rely on the presence or absence of files or directories in /usr/local for normal operation. how does that even remotely relate to your complaint ? the package itself just uses the default system paths and obviously doesnt *rely* on anything in /usr/local apparently ... No, but it *does* rely on the *absence* of a b0rken perl interpreter there. Yes. Although there's nothing broken about it, it's just a vanilla perl install and that means it doesn't have certain modules relating to DBus or gnome or whatever (I can't remember the exact error), F -- | Soren Hansen| Linux2Go | http://Linux2Go.dk/ | | Seniorkonsulent | Lindholmsvej 42, 2. TH| +45 46 90 26 42 | | [EMAIL PROTECTED] | 9400 Norresundby, Denmark | GPG key: E8BDA4E3 | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGQYsAonjfXui9pOMRAuBBAJwJT1VRHNBJFU3aB1CjUtZ07c/TdgCgmyMT pc5WblW6yW0Q52x/fMxIpj8= =hu4o -END PGP SIGNATURE- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
Fergal Daly wrote: Hi, I'm looking for clarification of policy in the context of this bug https://launchpad.net/ubuntu/+source/gnome-system-tools/+bug/71336 and the fact that having your own version of Perl in /usr/local will almost certainly break your Ubuntu admin tools. I have always assumed that it was safe to put whatever I like in /usr/local/ and my system will continue to work. This seems to be backed up by Debian policy http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit which contains this paragraph However, because /usr/local and its contents are for exclusive use of the local administrator, a package must not rely on the presence or absence of files or directories in /usr/local for normal operation. This seems quite sensible, otherwise it leads to mysterious and hard to track-down failures. Is this ubuntu policy too? Sorry, I have no idea what ubuntu policy is. But good defensive scripting practice includes setting your $PATH to something safe. A good script should always not trust the environment it was handed along with many other things that people don't always do. Jim I can't see any real benefit to including /usr/local/bin and I can find plenty of people in the forums who can't start *-admin, presumably due to problems similar to mine, F signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On 5/8/07, Fergal Daly [EMAIL PROTECTED] wrote: I can't see any real benefit to including /usr/local/bin and I can find plenty of people in the forums who can't start *-admin, presumably due to problems similar to mine, I personally use /usr/local/bin to install my own version of Firefox, without the need to uninstall the Ubuntu's version of Firefox. Since /usr/local/bin/ is ahead of /usr/bin in the standard $PATH of users, if I have a /usr/local/bin/firefox it is picked up by default by all my users. -- Daniel Robitaille -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On 08/05/07, Daniel Robitaille [EMAIL PROTECTED] wrote: On 5/8/07, Fergal Daly [EMAIL PROTECTED] wrote: I can't see any real benefit to including /usr/local/bin and I can find plenty of people in the forums who can't start *-admin, presumably due to problems similar to mine, I personally use /usr/local/bin to install my own version of Firefox, without the need to uninstall the Ubuntu's version of Firefox. Since /usr/local/bin/ is ahead of /usr/bin in the standard $PATH of users, if I have a /usr/local/bin/firefox it is picked up by default by all my users. You have quoted my last paragraph completely out of context. I put /usr/local/bin first in my path too, that's a perfectly fine use of /usr/local/bin and is not the problem. The problem is that when a system script puts /usr/local/bin first it can pick up all kinds of versions that don't do what it is expecting. In this case, /etc/dbus-1/event.d/70system-tools-backends picks will pick up a custom version of perl, expecting it to have the usual Ubuntu perl modules available and it fails. Worse, it fails silently, with the result that nobody (not even root) is authorised to run the admin tools. Shouldn't system scripts should only be invoking the system-supplied versions of binaries? F -- Daniel Robitaille -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
