/usr/local/bin in $PATH in system scripts?

[Fergal Daly]

On 10/05/07, Micah Cowan <micahcowan at ubuntu.com> wrote:
> Fergal Daly wrote:
> > On 10/05/07, Forest Bond <forest at alittletooquiet.net> 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