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: