Le lundi 16 février 2009 à 20:33 +0100, Matthias Klose a écrit :
> Besides the "normal" pending update of the python version for the
> unstable distribution, there will be more changes around python
> packaging, including the introduction of python-3.x and addressing
> some packaging issues.
It’s nice to have this status update, but why wasn’t this discussed on
debian-python first?
> There will be a `python3' package and similiar packages built out of a
> python3-defaults, which will provide the `python3' binary.
Good. That’s the only sane way to go.
> The use of a common location was proposed in 2006, but didn't get any
> feedback at this time. Last summer I did choose a name for this
> location, and a large part of packages already install into this
> location `/usr/share/pyshared'. For code shared between Python-3.x
> installations I propose to use `/usr/share/py3shared'.
Using the /usr/share/py*shared common location in python-support is
technically feasible, but it’s opening the door to letting
python-central break other packages than those using it, so this is
probably not going to happen.
> The choice of packaging helper should not add additional constraints
> on upstream software. To avoid these problems in the future, exactly
> one location for public python modules shold be used.
I have already explained why it is a bad idea to ship the installed .so
files and the symlinks directly in the /usr/lib/python2.X/site-packages
directories. I am certainly not going to change python-support for this
brokenness.
> - Not removing symlinked files and not removing byte-compiled files
> during upgrades. This only works reliable if the new version
> does neither remove nor add files, or else an inconsistent set of
> files in a package may be imported during an upgrade.
And that’s also what happens when files are updated by dpkg. At a given
time, there may be an inconsistent set of files installed on the system.
> There is still the issue of handling name space packages based on
> setuptools. Ideally existing techniques like diversions should be used
> for this, even if it looks loke overkill to divert the same empty
> __init__.py file.
Creating empty __init__.py files as needed is the role of the packaging
helper. This is what python-support already does in lenny.
> - The current policy advises packages to byte-compile only the
> files which a package owns itself. This is not done by several
> packages, with the result that an upgrade caused by a byte-
> compilation error may be attributed to the wrong package (makes
> the upgrade of an otherwise fine package fail).
A problem solved in python-support by using triggers and not failing for
a byte-compilation error.
> - The removal of a python version will cause the need for massive
> rebuilds. because many python extensions currently have
> dependencies of the form pythonX.Y-foo. There is nothing what
> can be done now for the upcoming removal, but those dependencies
> should not be there by default. This is 2.4 of the python policy,
> but many packages tend to ignore that.
There is a very good reason to add these dependencies. Ignoring the
requests to update the policy accordingly is not going to make the
problem disappear magically. Packages must not have a "Provides:
${python:Provides}" field if these dependencies are not present.
Otherwise, packages depending on this incorrectly provided version are
going to fail miserably.
Instead of this nonsense, the move to Python 3 sounds like the perfect
time to finally phase out python-central. Given the flaws in its design
and the lack of correct maintenance, there have already been several
reports of broken upgrades from etch to lenny that have been directly
caused by python-central. If you can’t fix it, please just drop it.
If you really want to improve the overall situation, maybe it is also
the time to think of fixing the interpreter for good instead of adding
layers of symbolic links farms. For example, if it was able to merge
several directory hierarchies in a single module hierarchy - like perl
had been doing in Debian for years before python-support was even
written - the overall needs for Python packaging would be greatly
simplified.
--
.''`. Debian 5.0 "Lenny" has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and
`- told that if you don't install Lenny, he'd melt your brain.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=