--nextPart1170332.3uA9vdqt0I
Content-Type: text/plain;
  charset="iso-8859-1"
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=
he
> > 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=
n=20
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=
at
> > 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=
o=20
posix compliancy. Your proposal is heading in the opposite direction and I=
=20
beg to disagree with you on this. The problem at hand is the result of our=
=20
attempts to cater for every possible scenario, an impossible task. What we=
=20
need is a clean and portable solution.

All this was working with earlier versions of pkgsrc. I'm a believer in "ke=
ep=20
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=
e=20
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=
=20
installed. pkg_alternatives and other solutions are unneeded fudges to solv=
e=20
a fundamental problem.

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

cheerio Berndt

--nextPart1170332.3uA9vdqt0I
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQBDSdEscUIHpeIRpjERAlopAJ9W81Gs85BMqPTBnBmLmQbMNzUlUwCgqkTM
acdKAWtRkjgzdB8RhV4cvt4=
=kmFf
-----END PGP SIGNATURE-----

--nextPart1170332.3uA9vdqt0I--