Re: Python modules for every supported version
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 <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Reply to: