Re: Packaging, supporting both 2.1 and 2.2
On Thu, May 23, 2002 at 04:34:18AM -0000, Moshe Zadka wrote:
> On Thu, 23 May 2002, abo@minkirri.apana.org.au (Donovan Baarda) wrote:
[...]
> > This situation is identical to the existing idle package. It's worth looking
> > at how it handles it.
>
> I'll take a look, thanks.
Note the naming convention 'pythonX.Y-foo' for the module and
'foo-pythonX.Y' for the executable were taken strait from the idle package
example. I use this convention thoughout my discussions.
> > 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.
That is the limitation of 1), addressed by 1a) and 1b) below.
> > 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 ;-)
You will not be holding python back... when python upgrades your 'foo'
package will become incompatible and end users will be forced to make the
decision "upgrade to python (2.2), or keep foo". Note that the foo-python2.1
and foo-python2.2 packages will still be OK. If your 'foo' never gets
updated, it should be dropped from the archive as any old incompatible
packages should.
There is a reason why the dependancies are structured this way... they say
'this package depends on the default python being installed, where the
default python is 2.1'. When the default python changes, this condition is
not met, and hence you package cannot be installed untill it is upgraded to
match the new python.
[...]
> > 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.
But the point is they can't choose to "support the default python". They are
forced to tie their own scripts/modules to a particular version of python,
and cannot take advantage of the way the policy can transperantly update the
default python to 2.2.
I really doubt that you will need to allow end users to choose which python
version to use when running /usr/bin/foo script. Sure, developers will need
the flexibility of using both python versions when using the foo.py module,
but when it comes to running 'foo', the default python would be sufficient.
For those that _really_ want to run foo with python2.2, they can run
'foo-python2.2' instead. I think using 'alternatives' is overkill for this
reason, and the symlink is a good idea.
> > 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.
See above. The python-foo package provides support for the default version
of python. There is no way around it... packages providing support for the
default version of python will need to be updated when the default version
of python is updated. However, since this is just a wrapper package with
nothing in it, anyone could NMU it by updating its dependancies.
Consider this; if you go MIA and the default python upgrades, is it better
to have your package silently broken, or for the dependancies to indicate
that it is broken?
> > 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 currently a package in need of testing :-) get it at;
http://people.debian.org/~calvin/python-central/
For python-central to fully work, the pythonX.Y packages need to use it so
that modules are automaticly added when a new pythonX.Y is installed.
However, without pythonX.Y support, python-central will still work fine when
modules that use it are installed.
> > 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.
I assume the 'dummy package python-foo' will be in the form of a "Provides:
python-foo". The problem with this is your dependancies will not "break" the
package when python upgrades, unless you have python2.1-foo with "Depends:
python (>=2.1), python (<<2.2), python2.1". You are starting down untested
ground if you go this way and have a package that is non-policy compliant.
I would recommend the following;
python2.1-foo (Depends: python2.1) has
/usr/lib/python2.1/site-packages/foo.py and /usr/bin/foo-python2.1 with
'#!/usr/bin/python2.1'
python2.2-foo (Depends: python2.2) has
/usr/lib/python2.2/site-packages/foo.py and /usr/bin/foo-python2.2 with
'#!/usr/bin/python2.2'
python-foo (Depends: python (>=2.1), python (<<2.2), python2.1-foo) has
symlink /usr/bin/foo to /usr/bin/foo-python2.1.
This allows developers to choose python2.1, python2.2 or python (default).
Sure, when you go MIA and python (default) upgrades, the python-foo package
will break, but there is no way around this when you provide support for
python (default). Remember that python-foo is a very simple wrapper package
that anyone could NMU, particularly if you have the d/r sorting it all out
for you.
> 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)'
The trick of finding the default python in d/r is a neat idea. I'm not sure
of all the implications of this, but you could certainly use this to
auto-build the python-foo dependancies and symlink(s). Perhaps this could
become part of the python-policy? I believe some work is going to happen
soon on python-policy support in debhelper.
If you really, really, _really_, are concerned about python-foo 'holding
back' python and don't want to support the default python, then you could
use my suggested plan, but omit the python-foo package and provide the
/usr/bin/foo symlink in python2.1-foo. If you do this, _DO NOT_ use any sort
of "Provides: python-foo", as 'python-foo' should indicate support for the
default python, and without the 'python-foo' package, you are not providing
true default python support.
--
----------------------------------------------------------------------
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: