Re: Packaging, supporting both 2.1 and 2.2
On Wed, May 22, 2002 at 04:50:02PM -0000, Moshe Zadka wrote:
> On Wed, 22 May 2002, Bastian Kleineidam <reflexionsniveau@web.de> wrote:
>
> > Ok, thats a problem. There is no way out for this; you'd have to
> > have two binaries.
>
> Yes, I know I'll have to have two binaries.
if I understand it, foo is not really a 'binary' but an 'executable
script'... (which means it can be Python version independant).
This situation is identical to the existing idle package. It's worth looking
at how it handles it.
You have several options if you want python2.1 and python2.2 supported;
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'.
1a) as 1), but also provide foo symlink for python (default).
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
1b) as 1), but also provide foo symlink using Debian alternatives.
as 1) but make packages foo-python2.1 and foo-python2.2 use Debian
alternatives for /usr/bin/foo.
The 1) options all force developers using foo.py to choose between 2.1 and
2.2. They cannot just depend on the default python, forcing them into
cascading package updates when they change python versions. The varients
simply provide different ways of making the foo script more accessable. The
following alternatives allow developers to depend on the default python and
minimise their package dates.
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'.
This follows the policy to the letter. It allows developers to use foo.py
with any of the three python versions. The python (default) is an alias for
2.1 in woody, but when the default changes to 2.2, packages that depend on
the default will not need to be updated to use it. When the default becomes
2.2, you just need to release a new python-foo (Depends: python (>=2.2),
python (<<2.3), python2.2-foo) wrapper package, and foo will automaticly be
using python2.2.
2a) have foo.py support python2.1, python2.2, python (default), incidentaly
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) with
/usr/bin/foo using '#!/usr/bin/python'.
This deviates from the policy a tiny bit in that python-foo is more than
just a wrapper package because it includes the /usr/bin/foo script. However,
it does eliminate one extra foo package and otherwise provides all the
benefits above.
3) use python-central to have foo.py support python2.1, python2.2, python
(default), provide foo using python (default)
make python-foo (Depends: python2.1 | python2.2, python-central), foo
(Depends: python, python-foo) with /usr/bin/foo using '#!/usr/bin/python.
3a) use python-central to have foo.py support python2.1, python2.2, python
(default), incidentaly provide foo using python (default)
make python-foo (Depends: python, python2.1 | python2.2, python-central)
with /usr/bin/foo using '#!/usr/bin/python'.
python-central is not part of the policy yet, and probably will not be in
woody. Using python-central would require you to put modules in
/usr/lib/python/site-packages and call 'register-python-package
(configure|remove) python-foo' in the postinst/prerm scripts.
how you provide python-foo and foo is fairly disjoint, and you can probably
mix-n-match the foo and python-foo packaging options (ie option 3
python-foo, option 1b foo), provided you carefuly think out the dependancy
implications.
--
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-python-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: