On Mon, Oct 10, 2005 at 08:08:44PM +0200, Jeroen Ruigrok/asmodai wrote:
> -On [20051010 11:53], Joerg Sonnenberger (joerg@britannica.bec.de) wrote:
> >(a) It depends on PATH. Yes, that's bad. It doesn't work from single
> >user environment, it doesn't work from the default cron configuration
> >etc.
> 
> Single user mode is only required for maintenance work.  This is not a valid
> reason for changing this in my opinion.

Have you ever had to deal with stupid administrators not knowing about
the special environmental situation of cron jobs? I had to last week, it
is not fun to debug. Using which adds one more point of failure.

> >(b) It means that changing the installed python version also forces the
> >change on all installed packages. It means the administrator can not
> >freely choose the version.
> 
> Yes, the administrator can freely chose the version, but you need to make
> sure that site-packages for the version is populated with the appropriate
> packages (part of which is version dependent due to the fact it will be
> compiled to bytecode).

The bytecode is not the problem, it is IIRC version independent. The
problem comes from installing into site-packages which is the usual
default and ABI / API differences. Minor differences are exactly why
hard-wiring the dependency is correct.

> >The only reason why scripts with #!/usr/bin/env python (or perl or
> >ruby) come up is that the stupid Linux mantra of software working out of
> >the box for every broken Linux installation. Guys, patching the script
> >as prat of the install stage to get the right interpreter is standard
> >behaviour and working perfectly fine.
> 
> Your reasoning is flawed and it has nothing to do with the supposed
> brokenness of a Linux installation.

No, the reasoning comes exactly the flawed "fix". Believing that any
interpreted language is a fixed, known interpreter name in PATH resulted
in the mess for Perl scripts. Please try to think about the implications
of using which.

> The same could be decreed of pkgsrc using /usr/pkg instead of /usr/local
> which has been the default for BSD local software since which year?
> Also this allows for a lot of flexibility which only depends on PATH
> toggles.

Noone forces you to install into /usr/pkg, but it allows you to properly
separate managed and unmanaged programs. I don't consider pkgrsc
packages part of the "local" software, it is somewhere between the base
system and local additions.

Again, I don't say you should stop using /usr/pkg/bin/python or which
python in unmanaged python scripts, but using either of it is just wrong
for a package management system. It completely defeats the purpose of
dependency checks.

Joerg