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

The new python policy and packaging



Hi,

        [Please keep the CC to debian-devel, or please CC me, if yu
        are replying to this on debian-python@lists.debian.org, since
        I am not subscribed to that list]

        I have been trying to ensure that my SELinux related packages
 which have a python component are compliant with the new Python
 policy[1].  The wiki page for the policy[2] seems to be mostly a dh_python
 usage manual, and defers to dh_python to set up the variable
 substitutions correctly, so I have been trying to write up my own
 manual based on the policy and reverse engineering dh_python.

        In the course of this, there were points which I found very
 confusing in the Python policy which I think need to be cleared up.

 Section 2.2:
        Firstly, public modules are supposed to be packaged in a
 package called python-foo. What about public extensions? section 2.2
 talks about naming, and also talks about supporting current python
 version. The last sentence in section 2.2 says:
         "This requirement also applies to extension modules; binaries
          for all the supported Python versions should be included in
          a single package."
 It is not clear whether "This requirement" refers to the naming, or
 the support.

        Perhaps policy should explicitly say "Public modules _and
 extensions_ should be packaged with a name of python-foo,"  (assuming
 that I now have the correct interpretation).

        (BTW, the wiki page seems to differentiate more strongly
 between modules and extensions:
 python extension: a .so file for use by python applications
 python module: a .py file for use by python applications)

section 2.4:
        Can anyone explain why if my python packages depend on Python
 version 2.4, and selinux.so for python 2.4, it should depend on
 python2.4 and python2.4-selinux; but when the default changes to 2,4,
 my package dependencies would beed to change to python (>= 2.4) and
 pythong-selinux? (This according to section 2.4 of [1])

        It is not clear why a package that depends strictly on python
 2.3, which is the current default, should fall into paragraph one of
 the section, and not into paragraph two.

,----[ section 2.4, paragraph 1 ]
|  Packaged modules available for the default Python version (or many
|  versions including the default) as described in Module Package Names,
|  Section 2.2 must depend on "python (>= X.Y)". If they require other
|  modules to work, they must depend on the corresponding
|  python-foo. They must not depend on any pythonX.Y-foo. 
`----

,----[ section 2.4, paragraph 2 ]
|  Packaged modules available for one particular version of Python must
|  depend on the corresponding pythonX.Y package instead. If they need
|  other modules, they must depend on the corresponding pythonX.Y-foo
|  packages, and must not depend on any python-foo 
`----

        I assumed it fell into paragraph one, since it is explicitly
 stated so in policy. Logically, though, only paragraph two should
 apply.  In any case, this must be disambiguated.

section 2.5:

        The second paragraph of section 2,5 is a duplicate of the
 second paragraph of section 2,4.  This seems like a cut-and-paste
 error, and directives appear to be missing from section 2.5. There
 should be something about providing pythonX.Y-foo if your package
 provides an extension for version X.Y of python.

        I'll add to this list as I get further along in my reading. 

        manoj

[1]http://www.debian.org/doc/packaging-manuals/python-policy/
[2]http://wiki.debian.org/DebianPython/NewPolicy

ps: I think policy should state clearly how it expects the various
fields in the control file to be initialized, rather than leaving it
mostly unstated and deferring to an external helper program, but that
is another thread
-- 
Without fools there would be no wisdom.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: