On Mon, Oct 10, 2005 at 11:55:32AM +0930, Berndt Josef Wulf wrote:
> On Mon, 10 Oct 2005 09:08, Joerg Sonnenberger wrote:
> > On Mon, Oct 10, 2005 at 08:52:24AM +0930, Berndt Josef Wulf wrote:
> > > pkgsrc doesn't install a ${LOCALBASE}/bin/python but a binary that has a
> > > version number attached to it. I presume that this was done to enable the
> > > concurrent installation of multiple python versions. How do I deal with
> > > the above problem when creating new packages? Is there an option that I
> > > can set to create a link from python${PYVERSION} to python as to enable
> > > standard script to find the python binary,
> >
> > pkg_alternatives.
> 
> This is fine for system owners that have a requirement to run different 
> versions of packages. However, this is not very useful for those with a 
> standard installation. For my part, I only ever had one version of python 
> installed at any one time, python2.3 and now python2.4. Installing more than 
> on version of a package is an exception rather than the standard.

Making it the default would mean you have to *predecide*, which is adds
a lot of hassle for all those who do need or end up with more than one
Python version installed. It is not as exceptunal as it might seem since
a lot of packages need an old version, but many run better with newer
versions.

> !#/usr/bin/env python
> 
> What's wrong with this? The scripts in discussion are as close as it gets to 
> posix compliancy. Your proposal is heading in the opposite direction and I 
> beg to disagree with you on this. The problem at hand is the result of our 
> attempts to cater for every possible scenario, an impossible task. What we 
> need is a clean and portable solution.

(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.
(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.

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.

> I should not have to jump through hoops in order to get things running 
> smoothly and properly in cases where only one version of an application is 
> installed. pkg_alternatives and other solutions are unneeded fudges to solve 
> a fundamental problem.

If you don't want to understand that there is no magic "it work
when only one version is installed" without serverly complicating the
"make it work with multiple versions" case, we don't need to discuss
this any further. If you are talking about anything outside pkgsrc, use
pkg_alternatives and live with the consequences.

> Perhaps we could go back to the drawing board and think of supporting standard 
> installation as our first priority and then find solutions for the exception 
> and at the same time comply to POSIX

POSIX has nothing to do this AT ALL. Where does POSIX specify a location
for the Python interpreter? Not even the (Linux) Filesystem Hierachie
Standard does that.

Joerg