On Wed, 2004-06-16 at 21:27, Fabio Tranchitella wrote: > Il mer, 2004-06-16 alle 04:03, Donovan Baarda ha scritto: [...] > Policy? What I missed? I tried to find a Debian Python policy, but I > didn't have enough luck. It is not listed on > http://www.debian.org/devel/ like the perl policy or the java policy... > So exists (or will exist, if actually doesn't) an official debian python > policy?
Have a look in /usr/share/doc/python/python-policy.html/. I think because it's draft it's not yet on the Debian website. It would be good if this was on the Debian website. > the users and create a lot of problems during the transitions. But as I > wrote before I understand a transition between two versions, but not > between three (2.1, 2.2 and 2.3). If the python2.1 packages required no overhead, other than disk space, why not leave them hanging around until no-one needs it? For example, it has been pointed out that Zope should really be using python2.1, and has been shoe-horned into python2.2, probably because the python2.1-foo support packages are starting to disapear. If there wasn't such a rush to blow away all the python2.1 packages, zope would probably still be using them. It is package updates that hurt mirrors (and users) the most; old packages hanging around don't need to be downloaded, just stored. > What about source and binary packages? For example python-psycopg source > package generates four pythonX.Y-related binary packages (yes, also some > others zope-related, I know ...) and a dummy package python-psycopg > which depends on python2.3 and python2.3-psycopg. > > Is this approch correct? Donovan suggests (as I understood) to build > different source packages for the different python versions (and/or for > the dummy package). Why shouldn't I use only one source package to build > python2.3-foo, python2.4-foo and python-foo (which switch the default > during the transition)? I was thinking mainly of the python package itself, where python2.3 is a different source package to python2.4. Packages where a single python-foo source package generates multiple pythonX.Y-foo binary packages are different. There are two different approaches you can take; 1) Have the python-foo source package generate all the pythonX.Y-foo and python-foo wrapper binary packages. When python upgrades from 2.3 to 2.4, release a new version of the python-foo source package that generates new-but-unchanged pythonX.Y-foo binary packages and a new python-foo wrapper binary package that depends on python2.4-foo instead of python2.3-foo. (ie, what is currently being done in many cases) 2) Have a single pythonX.Y-foo (where X.Y is not a number) source package that generates all the pythonX.Y-foo binary packages (where X.Y are numbers), and a python-foo source package that generates the python-foo wrapper binary package. When python upgrades from 2.3 to 2.4, release a new python-foo source package that generates a new python-foo wrapper binary package that depends on python2.4-foo instead of python2.3-foo. There is no need to release a new pythonX.Y-foo source package until you want to drop python2.1-foo support or add python2.5-foo support. > IMHO even if we can't drop python2.2 because zope (and other packages) > depends on it, we have to try to drop python2.1 and python2.1-* from > sarge. Having a quick look through the report, I think it isn't too > hard to drop them. >From looking at it, the main thing we'd loose by dropping python2.1 is jython. Anyone using it? I'd be happy to drop python2.1... -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/