Re: Packaging, supporting both 2.1 and 2.2
On Thu, 23 May 2002, abo@minkirri.apana.org.au (Donovan Baarda) wrote:
> if I understand it, foo is not really a 'binary' but an 'executable
> script'... (which means it can be Python version independant).
Yep.
> This situation is identical to the existing idle package. It's worth looking
> at how it handles it.
I'll take a look, thanks.
> 1) have foo.py support python2.1, python2.2, provide foo-python2.1 using
> python2.1 and foo-python2.2 using python2.2.
>
> make python2.1-foo (Depends: python2.1), python2.2-foo (Depends: python2.2),
> foo-python2.1 (Depends: python2.1, python2.1-foo) with
> /usr/bin/foo-python2.1 using '#!/usr/bin/python2.1', foo-python2.2 (Depends:
> python2.2, python2.2-foo) with /usr/bin/foo-python2.2 using
> '#!/usr/bin/python2.2'.
except there is no way to install something at "/usr/bin/foo". Users should
not *have* to care about python versions.
> 1a) as 1), but also provide foo symlink for python (default).
this makes sense....I can just put the symlink in python2.1-foo-bin and
move the symlinks when a python default change.
> as 1), but also make foo (Depends: python (>=2.1), python (<<2.2),
> foo-python2.1) with symlink /usr/bin/foo to /usr/bin/foo-python2.2
so that if I go MIA I'm keeping python back? ugh ;-)
> 1b) as 1), but also provide foo symlink using Debian alternatives.
Like I said, this is very high maintainence -- in real life, scripts
are added to upstream package frequently, and I don't want to echo
this in my postinst/prerm
> The 1) options all force developers using foo.py to choose between 2.1 and
> 2.2.
I don't think I mind that. developers can either support both or support
just one, and change which one they're supporting when they want to.
> 2) have foo.py support python2.1, python2.2, python (default), provide foo
> using python (default).
>
> make python2.1-foo (Depends: python2.1), python2.2-foo (Depends: python2.2),
> python-foo (Depends: python (>=1.1),python (<<2.2), python2.1-foo) wrapper,
> foo (Depends: python, python-foo) with /usr/bin/foo using
> '#!/usr/bin/python'.
Except that again, my package is holding up a default python change.
> 3) use python-central to have foo.py support python2.1, python2.2, python
> (default), provide foo using python (default)
AIUI python-central is still not there yet, correct? A lot of people are
already needing both 2.1 and 2.2 support, so I'll make do and when p-c
comes along, I'll see if I want to switch to it.
> python-central is not part of the policy yet, and probably will not be in
> woody.
woody is irrelevant -- I wouldn't make such changes in woody.
I'm thinking of doing 1a above -- people who don't give a damn won't care
about the versions and people who do can run "foo2.2" for all I care.
In short: installing python2.1-foo will have foo.py, /usr/bin/foo2.1 and
a foo->foo2.1 symlink. installing python2.2-foo will have foo.py,
/usr/bin/foo2.2 and no symlink. I'll create the symlink in d/r based on
the default python version on the build system, so rebuilding after python2.2
is default will cause the symlink to move from python2.1-foo to
python2.2-foo. it will also cause the dummy package python-foo to move from
depending on python2.1-foo to depending on python2.2-foo.
Unless anyone sees any problem with it, here is what I will use to find out
the default python on the build system:
/usr/bin/python -c 'import sys;v=sys.hexversion;print "%s.%s" % ((v>>24)&0xff, (v>>16)&0xff)'
--
To UNSUBSCRIBE, email to debian-python-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: