[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: