Debian Python policy.
G'day debian-python,
Just read the DWN, saw mention of the Python policy, read it, and subscribed to
this list to throw in some comments. I note that the policy was posted some
time ago, so these comments might be too late.
First off, you need to clarify what you are attempting to achieve. There are
three possibile aims as I see it;
1) single "official" version of Python in archive/distro.
2) multiple alternative versions of Python in archive/distro, only one
installed at a time.
3) multiple alternatives versions of Python installed at a time.
Option 1 means every time Python upgrades, all packages dependant on that
version of Python are broken and have to be upgraded, with old versions removed
from the distro.
Option 2 means every time Python upgrades, new versions of all version
dependant python packages are added to the archive/distro at the mantainers
lesure. Different versions of packages do not need to co-exist and must
conflict with each other.
Option 3 is similar to option 2, but different versions must be able to co-
exist and shouldn't conflict with each other. Mechanisms need to be in place to
ensure the correct version is used as needed.
Why would you want multiple versions available/installed? One reason is new
releases that are not backwards compatible, requiring old versions to run old
software. Another reason is new versions being experimental, so you'd rather
default to the old version but experiment with the new one.
Your policy seems to be aiming for Option 3... the hardest, but is that really
what we want? Option 2 looks viable to me, and is easier to achieve. Option 3
is highly suggestive of using the "alternatives" mechanism, which your policy
doesn't mention.
The policy says there should be a single python package of the latest version.
Only a single package can provide /usr/bin/python. This suggests that when
python upgrades, the old python package needs to be re-released as python-X.Y,
and a new python package released. This is ugly... better way is to always
release Python-X.Y packages, and use some mechanism to select which one
is "python". This can be done by all python-X.Y packages providing python. The
python-X.Y packages can then either all conflict with each other, or use
alternatives to select which is /usr/bin/python. Note that if it is desireable
to have a python package for some reason (apt-get funnies, version dependancies
etc), then have the python-X.Y packages provide python-base, and have the
python package depend on python-base.
The policy says that modules should be named python-foo and depend on python-
X.Y. This breaks Option 2 and option 3 because it only allows for a single
version of python-foo, which will be tied to a particular version of python. In
reality there are some modules that are tied to a particular version of python
(compiled against them), and some that are forwards compatible with some base
version (>=1.5). It would be nice if both types of packages could be handled
with a minimum of upgrading required.
I suggest modules that depend on python-X.Y should be named python-X.Y-foo,
allowing for multiple versions of version dependant modules. Other modules
should be named python-foo and depend on python (>=X.Y).
The lack of versioned provides makes things a little tricky... it would be nice
if python-X.Y could provide python (X.Y), so python-foo could depend on python
(>=X.Y) (though even this introduces new problems). Without versioned provides,
the best we can do is have installing python version X.Y depend on python-X.Y
(ie installing latest python always installs the latest python-X.Y). Note that
the same trick would need to be done with python-X.Y-foo packages... have a
python-foo version X.Y package that depends on python-X.Y-foo so that other
packages can depend on python-foo (>=X.Y).
There are heaps of fine details to nut out. I've got some more thoughts on
this, but this email is getting long enough, so I'll shut up now :-)
--
ABO: finger abo@minkirri.apana.org.au for more information.
Reply to: