Re: Python packages in incoming
Quoting Matthias Klose <doko@cs.tu-berlin.de>:
> Donovan Baarda writes:
> > Quoting Matthias Klose <doko@cs.tu-berlin.de>:
[...]
> > I don't see how this was such a showstopper. Getting the
> > dependancies right to ensure a clean transition would have been
> > fairly easy.
>
> Then again, why do we use versioned packages for C libraries? If I
> understand you right and translate your proposal for C libraries, then
> we should package libdb3 as libdb and libdb-dev. Now we upgrade libdb
> (v2) to the next version /v3). All packages that are broken by the new
> version have to be fixed by recompiling. And all packages that cannot
> be upgraded must be recompiled to use the now renamed libdb2 and
> libdb2-dev. Am I missing something? I cannot call such a transition
> "clean" and "fairly easy".
No. The modified scheme _did_ use versioned packages. It just added an
unversioned wrapper package that established which one was the "default" for
packages that didn't depend on a particular version.
As I stated (perhaps not clearly) much earlier, there are three ways to handle
multiple versions;
1) multiple versioned packages that conflict with each other
2) multiple versioned packages that coexist, using alternatives to select
a "default".
3) multiple versioned packages that coexist, with an extra "wrapper" package
that establishes the default.
Neil's original scheme of versioned packages + an unversioned default had the
flaws you are descibing, which is why I convinced him to go for 3).
> Why is Tcl/Tk packaged as a versioned package? You can leave the old
> package installed when a new version is uploaded. Every package can be
> upgraded in a safe way.
[...]
But with just versioned packages, you either rely on all other Python programs
to depend on a particular pythonX.Y, or you have them depend on "python" and
have all versioned packages provide "python", using alternatives to select
which one is the default. This introduces some tangled problems with
incompatible versioned extension packages. Assume the following is installed;
python1.5 (provides python)
python2.1 (provides python, higest priority alternative)
python1.5-eggs (provides python-eggs)
spam (requires python, python-eggs)
spam's dependancies are met but it is broken, because python2.1 is the default
alternative and python2.1-eggs is not installed. This is why Perl chose not to
use alternatives... what if spam happened to be dpkg? (I know, Python is not as
important as Perl)
The scheme proposed fixed all these, at the cost of having one extra
unversioned wrapper package to establish and force which version is the default.
> AFAICR the schema would package the newest version as python
> (unversioned) and the old version as pythonX.Y (versioned).
No, I convinced him that was a bad idea :-)
> > The biggest hassle with transition would be all the packages that
> > just depend on python and install themselves into
> > /usr/lib/python1.5. Until all of these packages have been upgraded,
> > the default python (whether provided by a python (1.5.2-xxx) wrapper
> > package, a python1.5 package, or a high priority alternative) has to
> > be 1.5.
>
> And you don't have the hassle when upgrading from 2.1 to the next
> version?
Not if you use the "modified" scheme Neil eventualy decided on. This required
version dependant packages like spam (requires pythonX.Y) to put themselves
in /var/lib/pythonX.Y/, but it also allowed version independant packages like
spam (requires python) to put themselves into /var/lib/python/ which a script
would link into all the /var/lib/pythonX.Y/ variants.
> [Assuming you mean this as Neil's last post]
> http://lists.debian.org/debian-python/2001/debian-python-200110/msg00028.html
Yeah... I just had a look again and saw that he said he would be away untill
the 17th... I guess he's going to catch up with this all in the next day or two.
Have a look again at that message, taking careful note of the positions of
the '-' and '_''s and you will see he is using versioned packages with a small
unversioned wrapper for establishing the default...
Note that he also advocates a transition plan of having python (1.5) establish
python-1.5 as the default untill all the broken packages that have (requires
python) and install into /usr/lib/python1.5/ are fixed.
> Managing the python binary without an alternative is the some approach
> as we do it with gcc. But this is not always understood (see #101731,
> #107587, #112887, #115353).
These all highlight the problems with using alternatives, particularly the last
one. I've just had a look at what gcc does and it seems they are doing what I
was advocating; gcc (2.95.x) (requires cpp, cpp-2.95, gcc-2.95) is a small
(3.2k) wrapper package that establishes gcc-2.95 as the default. cpp does the
same thing.
So if you've followed the gcc example, we're probably agreeing with each
other :-) I'll have a look at the packages when they come through.
--
ABO: finger abo@minkirri.apana.org.au for more information.
Reply to: