my changes proposals follow. {+ +} are part I've actually modified.
Le lun 7 août 2006 21:42, Manoj Srivastava a écrit :
> Hi,
>
> Here is round two of my take on python policy. I have
> incorporate the correction offered by various people, and read the
> documents for python-central and python-support, and incorporated my
> understanding of those into this document.
>
> So, this is my take on the new python policy, based on the
> analysis of the new Python policy draft and dh_python, and is
> supposed to be a rough specification of what the python policy is
> supposed to be (based on current dh_python behaviour). The current
> analysis, and future updates, are to be found at
> http://www.golden-gryphon.com/software/manoj-policy/
>
> This can still use a lot of polishing.
>
> I am including a text version below.
I'd add a § that explains the goals of the policy, that are unclear to
many people. Those are the following:
the new policy aims to reduce the pressure on packagers when
the /usr/bin/python version changes. In that case, it tries to:
* magically migrate packages that do not need *ANY* rebuild (pure
modules, private or public, they mostly only need new byte
compilation)
* packages that have already an extension built for the new python
package. E.G. current packages with public extensions for python2.3
and python2.4 does not need anything to work when python2.4 will
become default.
It aims also to reduce the pressure when a new pythonX.Y version will be
introduced. e.g., when python2.5 will arrive:
* most pure modules that have 2.3-, all, or alike pyversions will just
work (only need some bc which pycentral/pysupport will do)
* only need a binNMU for public extensions:
o packages using $(shell pyversions -s) to know for which python
versions to build for, and B-D upon python-all-dev will just work.
o same for cdbs packages, and distutils ones.
==> here you should talk about pyversion (the /usr/bin/pyversion) and
its -d and -s options.
* only need a binNMU for private modules (will work if the package uses
pyversions -s to determine the python version to build for).
It endly also aims to reduce the pressure when an old pythonX.Y is
dropped, as only the packages *directly* depending on that pythonX.Y
version will need an manual upgrade (meaning the packages using
#! /usr/bin/pythonX.Y). the rest is again a matter of automated gestion
of the byte compiling, or binNMU to remove the extensions built for
that version of python.
One could also argue that the new policy greatly reduce the number of
packages in the archive (often 1 instead of 3 for the old policy) to
the cost of having many .so for different pythonv versions in the same
package, wich is a bit ugly. but this saves a lot of entries for
dpkg/apt, and also wins a lot of space for pure modules that are almost
always identical for different python version (meaning that currently
most of the pythonX.Y-foo for pure modules are just identical packages,
except for the /usr/lib/pythonX.Y path...)
The only packages that will need manual upgrades, are packages that
needed a range of python versions that did not contained the (at the
upload time) current python version, and a couple of other cases, wich
should reduce the packages that need a real (like in non automatable
way) action of the packager (like a source full upload). that will
mostly happen for packages that will begin to support
the /usr/bin/python in debian. That should makes the number of packages
that need manual things go from sth like 700 to sth like 50, wich makes
transitions mostly painless (wrt as a current full one).
§ 1.1, definition of Public modules:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This part is well worded IMHO. I'd instead say:
--------------8<-----------------------------------------------------
Public modules are available for use in other Python scripts or
modules using the import directive. They are installed in one of the
directories:
{+
o /usr/lib/pythonX.Y (for official python modules, nobody else than
upstream official python modules should live in there)
o /usr/lib/pythonX.Y/site-packages
Packages using python-support also see their public modules be linked
from /usr/lib/python-support/pythonX.Y, but nobody should directly
install anything here by itself.
+}
Packages may install public Python modules in directories specific
to Python packaging utilities -- which specify the directories under
which such modules should be droppped, and the the structure of
these directories is defined by the utilities themselves. Please
note that these directories are not in the path for Python, and are
not available for modules to be imported from. At the time of
writing, such uility specific directories include:
/usr/share/pycentral
/usr/share/python-support
-------------->8-----------------------------------------------------
§ 2.2.2: Depends
~~~~~~~~~~~~~~~~
the depends algorithm is just wrong IMHO, dh_python does really
curious and complicated things, and I really think it's broken.
basically, Depends should be computed like that:
(1) if any script uses /usr/bin/pythonX.Y, then the package *must*
depend upon pythonX.Y
(2) an added dependency on python (>= x0.y0), python (<< x1, y1) has
to be used for the larger interval containing the current X.Y. If
one of the boundary does not exists, it can be dropped. If any
python version is supported, it shall use `python'.
The rest is pure s**t from dh_python.
as a "test suite", with current beeing 2.3, here are the deps
generated by my rule #2:
debian/pyversions | depends on python
----------------------------+-------------------------------
2.1- | python (>= 2.1)
all | python
current | python (>= 2.3), python (<< 2.4)
| (I'm not 100% sure of that one "current"
| semantics is a bit broken IMHO)
2.2-2.9 | python (>= 2.2), python (<<2.10)
2.1-2.2,2.4- | *SHOULD NOT HAPPEN*
BUT no package should use /usr/bin/python if it needs a python
version strictly greater (or strictly lower, but that's IMHO never
the case for known versions of python) than the current. It's IMHO
broken for many packages.
§ 2.3.3, 2.4.2, 2.5.3, 2.6.2:
*here* the python$version alternative is correct,
because /extensions/ can be used with a '/usr/bin/python' as soon as
the python current version is in their supported range.
so take the previous algorithm, and add to (2): if current python
version isn't in that range, add an alternative to the pythonX.Y
corresponding to the range lower bound. Meaning that in my test cases,
instead of *SHOULD NOT HAPPEN* you will get:
python (>= 2.4) | python2.4
and in fact, wrt Depends, the algorithm for pure modules or extensions,
private or public is the same. (except for the XB-P-V thingy
and "current" but again, that seems broken to me, and in fact, even if
I do consider XS-P-V as very useful, I still cannot see XB-P-V as
anything else than a pycentral implementation choice)
You should also mention that a package that mixes many of the previous
items *SHOULD* depend of all the pythonX.Y from the (1) clauses, and
the smallest range obtained from the (2)'s. and a
python (>= X.Y) | pythonX.Y *IS* invalid as soon as scripts
using /usr/bin/python are involved.
You also totally miss the rtupdate thingy, that would IMHO need a
chapter 3.
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpDh3OtC4upv.pgp
Description: PGP signature
