On Thu, 2006-07-27 at 11:56 -0500, Manoj Srivastava wrote: > 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) Your confusion is due to an incorrect distinction. .py and .so files are both modules; .so files are "extension modules" and .py files are "pure Python modules". When the word "module" is used alone it always refers to both. This is made clear in the policy; http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s2.1 If the wiki uses "modules" to refer to only pure Python modules, it is incorrect. > 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? Because then applications using the default python (/usr/bin/python) can access it, and that will be true for versions beyond 2.4. The versioned names are not appropriate for packages using the default version. If you always need Python 2.4, even when Python 2.5 is the default, then the python2.4-foo deps are still appropriate. > 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. I would not consider modules for only 2.3 to be available "for the default Python version", unless a simple rebuild would make them for only 2.4 after 2.4 becomes the default (XS-Python-Version 2.3 versus XS-Python-Version current). And if your module supports more than one version, you should be packaging it for more than one version, meaning it unambiguously falls under 2.4.1. The language could perhaps be clearer, but you're the first person to have problems with it (and you figured it out as well), so I think it's adequate. > 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. Yes, this is a real mistake, probably my fault. The second paragraph can probably just be deleted. The Provides: has nothing to do with extensions. It's solely to do with whether or not version-specific modules or programs need to use your module. It can be appropriate for pure Python modules, or pointless for extensions that are not required by anything version-specific. > 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 Until dh_python's behavior stops changing every other week this is an act of futility. I tried to emphasize this previously, but it seems to be a lost cause. Packaging Python programs is going to require debhelper or CDBS, as well as pysupport or pycentral, for the forseeable future. I realize this will make you very unhappy, but it's just something you will have to deal with for now. -- Joe Wreschnig <piman@sacredchao.net>
Attachment:
signature.asc
Description: This is a digitally signed message part