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

Re: Python packages in incoming



Donovan Baarda writes:
> Quoting Matthias Klose <doko@cs.tu-berlin.de>:
> 
> > Jérôme Marant writes:
> > >   What about proposal and policy from Neil and his efforts?
> > 
> > - the proposed packaging scheme doesn't allow smooth upgrades between
> >   one python version and a next version. compare python-1.5 to libc5
> >   and python-2.1 to libc6. there was a clear upgrade procedure to do
> >   the transition. The proposed packaging scheme doesn't allow such an
> >   upgrade. From my point of view, this is a showstopper.
> 
> 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".

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.

> If I recall correctly, Neil's last post was that he was preparing some test 
> packages that did adopt these extensions. I would be very surprised if the 
> transition to this scheme was not addressed by Neil.

AFAICR the schema would package the newest version as python
(unversioned) and the old version as pythonX.Y (versioned).

> 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?

[Assuming you mean this as Neil's last post]
http://lists.debian.org/debian-python/2001/debian-python-200110/msg00028.html

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).



Reply to: