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

Re: dh_python and python policy analysis



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                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpnlmWLZTERB.pgp
Description: PGP signature


Reply to: