Re: Summary of python transition problems
On Tue, 2003-10-14 at 04:29, Matthias Klose wrote:
> Colin Watson writes:
> > On Tue, Oct 07, 2003 at 07:28:23PM +0200, Matthias Klose wrote:
> > > Colin Watson writes:
> > > > For what it's worth, I think a python-defaults source package or some
> > > > such would help: at the moment there are several packages needlessly
> > > > stalled on python2.3, even though their dependencies are simply
> > > > 'python2.3 (>= 2.3)' or similar. If the python binary package were built
> > > > from a separate source package then we could decouple transitions from
> > > > the task of keeping the versioned packages up to date.
> > >
> > > It does help for python applications, which depend on an explicit
> > > python version. I did not count packages with a 'python2.3 (>= 2.3)'
> > > dependency.
> > >
> > > It does not help for library packages building a python-foo binary
> > > package. For this case you would have to separate this binary package
> > > to build from it's own source (but maybe this could be built from the
> > > python-defaults package as well ...).
I assume you mean pythonX.Y-foo binary packages being built from a
python-foo source package that also builds the python-foo wrapper
package.. and are suggesting that all python-foo wrappers instead be
build from a common python-default source package...
> > Hmm. How many python-foo binary packages are there? (I count 138 in
> > testing. Ouch.) How feasible would it be to have at least some of the
> > core ones all built from a hypothetical python-defaults?
I don't think this is the right approach to take. A "better" approach
would be to have dummy python-foo source packages that just build the
python-foo wrapper. This way you don't have one centralised mother of a
package that is aware of all python packages.
However, this would probably be uglier than most would be prepared to
consider :-)
> > This is blue-sky - I'm not involved enough in Python to know whether
> > it's feasible, unfortunately. I have a feeling that it might cause
> > different problems.
>
> After two python transitions I am unsure if python-foo binary-arch
> packages are a good idea ... Most packages depending on python-foo
> have to be recompiled/reuploaded anyway, so having them to explicitely
(in the following, '[...]' indicates EBNF style "optional" text)
Yeah... at the time the Python Policy was formulated, we didn't really
consider the complications introduced by having the pythonX.Y[-foo]
packages _and_ the python[-foo] wrapper built from the same
python[X.Y][-foo] source package.
We didn't take into account that packages are built and transition into
testing based on source packages, not binary packages. This means
generating a new python[-foo] wrapper requires a new python[X.Y][-foo]
source package, which generates new pythonX.Y[-foo] packages anyway.
The worst case is when you have different pythonX.Y[-foo] source
packages for different versions of pythonX.Y[-foo]. This means you need
to update both pythonX.Y[-foo] source packages so that the old one
no-longer generates the python[-foo] wrapper, and so the new one does.
In this case a separate python[-foo] source package to just generate the
python[-foo] wrapper kinda makes sense...
I think in some cases multiple pythonX.Y-foo packages are built from a
single python-foo source package. In this case a separate source package
to generate the python-foo wrapper doesn't make sense.
I'm not sure what the best solution is... certainly depending explicitly
on pythonX.Y[-foo] packages instead of python[-foo] wrappers is proving
to be more robust. Perhaps python is the only package that should have a
wrapper generated from a separate python source package? (ie, python2.2
source and binary, python2.3 source and binary, python source and
wrapper).
Dunno... need to think on it more.
> depend on pythonX.Y-foo is not a big burden. The pythonX.Y schema was
> never meant to allow permanent parallel installation of python
> versions, but to ease the transition between versions.
I would disagree with this statement... the original policy had as one
of it's explicit objectives the ability to have multiple parallel
installations of different Python versions. The python1.5 to python2.x
transition was non-trivial, and meant we needed to support python1.5 for
a long time after python2.x was the default.
I still think this is worth while... many Python developers work with
multiple versions of python (I use 2.1, 2.2, and 2.3 regularly for
different purposes)
As an end user who used to live on a modem, I also think it's worthwhile
to minimise unnecessary updates. Updates that just change dependencies
should be minimised, and updates that don't change anything should be
avoided. Currently we are generating updated python2.2[-foo] packages
that are identical to the old ones in every way except that they are
generated from a different python2.2[-foo] source package that no-longer
generates a python[-foo] wrapper.
--
Donovan Baarda <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Reply to: