Subject: Re: python binary
To: Joerg Sonnenberger <>
From: Berndt Josef Wulf <>
List: tech-pkg
Date: 10/10/2005 11:55:32
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 t=
> > 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=20
versions of packages. However, this is not very useful for those with a=20
standard installation. For my part, I only ever had one version of python=20
installed at any one time, python2.3 and now python2.4. Installing more tha=
on version of a package is an exception rather than the standard.

> > I believe that it is impractical to patch hundreds of python scripts th=
> > get installed with packages such as GNU Radio, especially when they do
> > the right thing.
> No, they don't do The Right Thing (TM). For once, they depend on PATH to
> have a sane value, which might result in security problems or not work
> at all depending on the context. It also doesn't work with the
> dependency framework, since a package build against Python 2.4 should
> not start using 2.3 just because the admin wants that as default for new
> users. The Right Thing for the scripts would be to allow easy patching
> e.g. via sed. The replace support in pkgsrc for that.

!#/usr/bin/env python

What's wrong with this? The scripts in discussion are as close as it gets t=
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.

All this was working with earlier versions of pkgsrc. I'm a believer in "ke=
it simple stupid" (KISS). The current pkgsrc implementation is most=20
definitely not and quite the opposite. It's a royal pain in the neck to wad=
through the jungle of undocumented code to get things working properly.=20

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

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

cheerio Berndt

Content-Type: application/pgp-signature

Version: GnuPG v1.4.2 (NetBSD)