Bugs that'll block python 2.5
Adeodato Simó
Yesterday about 100 binNMUs (per arch) were scheduled to rebuild stuff
against the new default python version.
amd64 and others seem to have attempted them all already, so I took a
peek at what failed, and tagged the existing bugs (or submitted new
ones) with the "goal-python2.5" usertag.
So, you can find a list of the 9 FTBFSes that need attention here (these
are not 7 days old yet, but patches would be always welcome):
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=goal-python2.5;users=debian-...@lists.debian.org
There is also in that list a couple trivial uploads that'll be needed
(#476170 and #476173, though a proper patch for #476173 would be nice).
Finally, and quite importantly, there is what to do with modules that
have been added to the standard library in 2.5 (ctypes, celementtree,
wgsiref). These use either pycentral or pysupport, and since they mark
themselves as for python << 2.5 only, the dependency generated is on
python (<< 2.5), rendering them uninstallable.
This means that these three packages either are to be dropped, or
(preferably) fixed so that they can provide modules for python 2.4
(which will still be supported for lenny), yet be co-installable with
python=2.5.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
«Ara que ets la meva dona, te la fotré fins a la melsa, bacona!»
-- Terenci Moix, “Chulas y famosas”
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Raphael Hertzog
> Finally, and quite importantly, there is what to do with modules that
> have been added to the standard library in 2.5 (ctypes, celementtree,
> wgsiref). These use either pycentral or pysupport, and since they mark
> themselves as for python << 2.5 only, the dependency generated is on
> python (<< 2.5), rendering them uninstallable.
I think they should simply be updated to not use ${python:Depends}.
I wonder if that should be replaced by some custom dependency however.
Probably not. There's no reason to depend on python-2.4... that's the
job of packages containing python scripts requiring 2.4.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Piotr Ożarowski
> On Mon, 14 Apr 2008, Adeodato Simó wrote:
> > Finally, and quite importantly, there is what to do with modules that
> > have been added to the standard library in 2.5 (ctypes, celementtree,
> > wgsiref). These use either pycentral or pysupport, and since they mark
> > themselves as for python << 2.5 only, the dependency generated is on
> > python (<< 2.5), rendering them uninstallable.
>
> I think they should simply be updated to not use ${python:Depends}.
> I wonder if that should be replaced by some custom dependency however.
> Probably not. There's no reason to depend on python-2.4... that's the
> job of packages containing python scripts requiring 2.4.
I guess my mail from yesterday didn't make it... anyway, ctypes and wgsiref
are already fixed (I will file bugs against python-support and python-central
later) and celementtree should be fixed by binNMU (it worked on my
desktop)
Josselin Mouette
> Finally, and quite importantly, there is what to do with modules that
> have been added to the standard library in 2.5 (ctypes, celementtree,
> wgsiref). These use either pycentral or pysupport, and since they mark
> themselves as for python << 2.5 only, the dependency generated is on
> python (<< 2.5), rendering them uninstallable.
The solution is really simple, just add them to python’s Provides: list.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
Adeodato Simó
> On lun, 2008-04-14 at 22:57 +0200, Adeodato Simó wrote:
> > Finally, and quite importantly, there is what to do with modules that
> > have been added to the standard library in 2.5 (ctypes, celementtree,
> > wgsiref). These use either pycentral or pysupport, and since they mark
> > themselves as for python << 2.5 only, the dependency generated is on
> > python (<< 2.5), rendering them uninstallable.
> The solution is really simple, just add them to python’s Provides: list.
That's a good point, but that's about rdepends only, and orthogonal to these
packages being uninstallable.
Anyway, FTR, all three packages have been uploaded like this:
python-wsgiref (0.1.2-3) unstable; urgency=medium
.
* Replace ${python:Depends} with "python (<<2.5) | python2.4,
python-support (>=0.6.4)" as python-support generates wrong dependencies
(and makes this package uninstallable with python2.5 set as default)
celementtree (1.0.5-10) unstable; urgency=low
.
- don't use ${python:Depends} in depens fields so
that the package can coexist with python >= 2.5 (Closes: #475897)
ctypes (1.0.2-3) unstable; urgency=medium
.
* Change "all" to "<<2.5" in XS-Python-Version and let python-central
generate dependencies, add python2.4 to Depends (closes: #475906)
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Carlos Berlanga - Septiembre
Adeodato Simó
> On lun, 2008-04-14 at 22:57 +0200, Adeodato Simó wrote:
> > Finally, and quite importantly, there is what to do with modules that
> > have been added to the standard library in 2.5 (ctypes, celementtree,
> > wgsiref). These use either pycentral or pysupport, and since they mark
> > themselves as for python << 2.5 only, the dependency generated is on
> > python (<< 2.5), rendering them uninstallable.
> The solution is really simple, just add them to python’s Provides: list.
Plus, uhm, can't really be done for (c)elementtree, since python 2.5
provides the modules under a different name/namespace.
Which leads to the interesting question of whether some program is going
to break by this (the dependency will be satisfied, but the modules
won't be available under the names where the program *may* be expecting
them).
python-pysqlite2, on the other hand/for example, still provides the
modules for python 2.5 under the old name. elementtree could do this,
or else the packages should be somehow checked, I guess?
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Carlos Berlanga - Sueños
Piotr Ożarowski
> On lun, 2008-04-14 at 22:57 +0200, Adeodato Simó wrote:
> > Finally, and quite importantly, there is what to do with modules that
> > have been added to the standard library in 2.5 (ctypes, celementtree,
> > wgsiref). These use either pycentral or pysupport, and since they mark
> > themselves as for python << 2.5 only, the dependency generated is on
> > python (<< 2.5), rendering them uninstallable.
>
> The solution is really simple, just add them to python’s Provides: list.
python2.5 package already does that, the problem was that python-support
generated something like "python (<<2.5)" for "2.1-2.4", anyway, Depends
are filled in by hand in python-wsgiref package and I will file a bug in
python-support after work. In python-ctypes there was a different
problem - XS-Python-Version's content was wrong (I changed "all" to
">=2.1, <<2.5")
Josselin Mouette
> [Josselin Mouette, 2008-04-15 12:32]
>
> python2.5 package already does that
But python does not:
Provides: python-email, python-xmlbase
> , the problem was that python-support
> generated something like "python (<<2.5)" for "2.1-2.4", anyway, Depends
> are filled in by hand in python-wsgiref package and I will file a bug in
> python-support after work.
This behavior is intentional; if python-foo only supports python << 2.5,
introducing a dependency on python (<< 2.5) | python2.4 will just break
all python-foo’s reverse dependencies, allowing them to be installed
with python 2.5 while they can’t work with it.
Thus, there needs to be some special-casing for modules being moved to
core python packages. As they are doomed to be removed soon enough, I
think they can live with some manual dependencies.
Raphael Hertzog
> * Josselin Mouette [Tue, 15 Apr 2008 12:28:00 +0200]:
>
> Plus, uhm, can't really be done for (c)elementtree, since python 2.5
> provides the modules under a different name/namespace.
?!
In that case it might be a good idea to build python-celementtree for
python 2.5 as well... I haven't heard of technical incompatibility but
just that it was bundled with python 2.5 and thus unneeded/in conflict.
But if the namespace is different, there's no file conflict and I don't
understand why we cared about not generating the module for python 2.5.
> python-pysqlite2, on the other hand/for example, still provides the
> modules for python 2.5 under the old name. elementtree could do this,
> or else the packages should be somehow checked, I guess?
Indeed. (I should read mails entirely before replying :))
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Matthias Klose
> On Tue, 15 Apr 2008, Adeodato Sim ,AC3 (B wrote:
> > * Josselin Mouette [Tue, 15 Apr 2008 12:28:00 +0200]:
> >
> > Plus, uhm, can't really be done for (c)elementtree, since python 2.5
> > provides the modules under a different name/namespace.
>
> ?!
>
> In that case it might be a good idea to build python-celementtree for
> python 2.5 as well... I haven't heard of technical incompatibility but
> just that it was bundled with python 2.5 and thus unneeded/in conflict.
no, it's not needed, and should be fixed in the package instead. This
is already done by almost all code.
Matthias
Tristan Seligmann
> On Tue, 15 Apr 2008, Adeodato Simó wrote:
> > * Josselin Mouette [Tue, 15 Apr 2008 12:28:00 +0200]:
> > > The solution is really simple, just add them to python’s Provides: list.
> >
> > Plus, uhm, can't really be done for (c)elementtree, since python 2.5
> > provides the modules under a different name/namespace.
>
> ?!
>
> In that case it might be a good idea to build python-celementtree for
> python 2.5 as well... I haven't heard of technical incompatibility but
> just that it was bundled with python 2.5 and thus unneeded/in conflict.
Since elementtree/celementtree is still released as a standalone module,
a program or library might be using newer features that aren't available
in the stdlib version; this would be more complex to fix than just a
simple try/except ImportError.
> But if the namespace is different, there's no file conflict and I don't
> understand why we cared about not generating the module for python 2.5.
I'm not really sure either; it seems over-eager to get rid of the
standalone module, even if most software can be fairly easily fixed to
import the module from either location.
--
mithrandi, i Ainil en-Balandor, a faer Ambar