[un]versioned python dependency?

[Jan Nieuwenhuizen <janneke@gnu.org>]

Hi,

I've had a small discussion with Julian Gilbey, packager of pktrace.
Julian decided to make pktrace depend on python2.1, while pktrace does
not depend on a specific python version per se.

He asked me to take it up with you list; because I could do without the
python2.1 dependency, but Julian doesn't see any other sane solution
than to depend on a specific python version: when python gets
upgraded, who's going to copy/move/recompile the modules?

On Mon, Mar 18, 2002 at 03:01:40PM +0100, Jan Nieuwenhuizen wrote:
> Hi Julian,
> 
> Thanks for packaging pktrace, it's real cool to have this in Debian
> already.  However, today I tried to install it on our (shared)
> autobuild server, and found that pktrace depends on python2.1.
> Han-Wen says that's not necessary.
> 
>     Depends: python2.1, autotrace (>= 0.29), t1utils, tetex-bin, libc6 (>=
> 2.2.4-4)
> 
> Because of all kinds of incompatibilities and breakages in python2.1,
> I don't want to install it on this shared server (that runs zope, eg.)
> 
> It would be very nice if you could fix this

Here's the difficulty when using Python under Debian.  /usr/bin/python
is part of the python package, and is a symlink to python2.1.  So were
I to depend on python instead of python2.1, you'd have the same
problem.  Next, I could assume that the sysadmin is maintaining the
/usr/bin/python link and depend on python2.1 | python2.2, and have the
#! line read /usr/bin/python.  But then where do I put my optimised
python code?  I could put it in /usr/lib/pktrace, which is where Hans
intended.  But then what happens when a regular sysadmin upgrades
python from 2.1 to 2.2?  OK, now let's try putting it in
/usr/lib/python2.1 *and* in /usr/lib/python2.2 (symlinking).  Then on
configuring the package, do the following:

if [ -x /usr/bin/python2.1 ]; then
   compile for python2.1
fi
if [ -x /usr/bin/python2.2 ]; then
   compile for python2.2
fi

That's doable, but it's a bit grim, and it still doesn't properly
handle the Python upgrade problem.

So essentially the answer is: the current Debian Python setup is not
yet able to cleanly handle this situation.  That is why I have used a
specific python version.  I recommend that you raise this issue with
the debian-python list and see whether we can arrive at a better way
of doing things so that this sort of problem can be avoided in the
future.

   Julian

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org