Joerg Sonnenberger wrote:
> 
> Yes, there are examples of that. The number for which the version change
> just works is limited though. You can't install to the site dir for
> example. That's a problem already for those packages which are not
> versioned, e.g. bittornado.  Install python24 on a fresh system,
> net/bittornado, python23 and net/bittornado-gui and wonder :-)
> 
> Really, nothing in pkgsrc should depend on ${LOCALBASE}/bin/python, it
> is evil. For those crying, please keep in mind that the behaviour is
> also the default on other systems like Debian.

I pondered this exact problem for package views.  The solution I was 
going to implement (but haven't yet gotten around to) was symlink the 
correct versioned python binary somewhere into the package tree, then 
make all of the package's python scripts use that symlink path.  Mapping 
that idea to current pkgsrc, that would mean, e.g. for the bittornado 
package, we symlink /usr/pkg/bin/python2.4 to 
/usr/pkg/libexec/interpreters/bittornado-python, then we make the 
bittornado *.py scripts start with:

	#! /usr/pkg/libexec/interpreters/bittornado-python

This way, regardless of what other python packages you installed on the 
system or what your PATH looked like, bittornado would always use the 
python binary from the package named in its dependency list.  Also, 
unmanaged scripts can do whatever they want, i.e. hardcode a specific 
python binary, or use the well-known env PATH trick.

This idea needs some small refinements to work correctly with binary 
packages with open-ended dependencies, but those are easy to figure out.

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>