Re: Python3 experimental packages with destination squeeze
Hello,
On Wed, Sep 15, 2010 at 01:53, Matthias Klose <doko@debian.org> wrote:
> In experimental you'll find a set of packages for Python3
>
> python3.1 3.1.2+20100909-1
> python3.2 3.2~a2-4
> python3-defaults 3.1.2-10
> python-defaults 2.6.6-2
> distribute 0.6.14-3
>
> The python3.2 package has the PEP's 3147 (PYC Repository Directories)
> [1] and 3149 (ABI version tagged .so files) [2] implemented, which
> allows installation of .so and .py[co] files for different python
> versions in one directory. The above packages do use a common
> directory as the site directory for "public" packages
> (/usr/lib/python3/dist-packages). distutils and distribute/setuptools
> are patched to install into this site directory by default when using
> the --install-layout=deb option. dh_python3 knows how to handle these
> locations. When building packages, a build dependency on a minimum
> version 3.1.2-10~ for one of the python3-* packages is needed.
>
> The part of PEP 3149 for looking up .so files with the ABI version is
> backported to python3.1.
>
> Currently there are only a few packages in the archive depending on
> python3, some of which already use the new location, I'd like to see
> the rest of the packages converted too, so that these few packages can
> ship with squeeze.
>
> * beaker 1.5.4-3
> * mako 0.3.4-4
> * sqlalchemy 0.6.4-2
> * markupsafe 0.11-2
> * jinja2 2.5.2-3
> * distribute 0.6.14-2
> * pycxx 6.2.0-3
> * gearman-interface
> * lxml 2.2.8-1
> * python3-httplib2
> * python-slimmer
> * pyyaml
> * python-bsddb3 4.8.3-2
> * python-apt (python3-apt binary package is missing)
>
> Packages mentioned here with version numbers are already updated, in
> experimental, in NEW, or being uploaded (Scott will care about pyaml,
> Piotr will care about the remaining ones, I'll contact the python-apt
> maintainers about the python-apt split).
>
> A small howto for packaging with python3 can be found here [3]. There
> is a freeze exception/pre-approval granted by the release team [4] for
> new "popular" binary python3-* packages as long as these are built
> from the same source and don't introduce new upstream versions.
Something I didn't find written anywhere and makes me wonder is:
what's the gain for squeeze to have those new packages? is 3.1 being a
supported version depending on those packages or viceversa? (after
all, why have 3.1 as supported without any modules?)
We are quite late in the release cycle, so what's the advantage to
have all this work rushed to be included in squeeze?
Some of the above mentioned py3k packages have such a low popcon they
don't even worth to be mentioned (slimmer, bsddb3, and then
gearman-interface that has 0 popcon), and the others are unluckily to
be used "alone" but much more probably they are part of some bigger
applications (scripts) and so unless you convert a lot more packages
and the apps themselves, when the converted packages will be used?
Also python3 does not have yet a stable workflow (that means
interpreter, dh_python3, debhelper, python-support, etc etc receive
continue uploads to fix that, introduce a new feature for py3k pkgs,
and so on) and so I can't see the point in just throwing a bunch of
modules converted with 2to3 into the release. Upstreams are releasing
their codes compatible with both 2.x and 3.x, but it's a slow process.
If it just a prove of concept, then why not skipping squeeze and wait
for a much wider adoption of py3k in the world (so with proper,
upstream-checked python3-compatible modules released) and postpone
this for wheeze?
I hope you can clear my doubts.
Regards,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Reply to: