Re: The new python policy and packaging
On Thu, 27 Jul 2006 14:15:47 -0500, Joe Wreschnig <piman@sacredchao.net> said:
> 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.
Then please explain section 2.2:
"Public modules should be packaged with a name of python-foo, where
foo is the name of the module. <snip> This requirement also applies
to extension modules; binaries for all the supported Python versions
should be included in a single package. "
The wording implies that Public modules are distinct from
extension modules (since something stated for public modules
also applies to extension modules. Policy otherwise states public vs
private and pure modules vs extension modules are orthogonal, so
there is an inconsistency here.
> This is made clear in the policy;
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s2.1
Inconsistently so, as noted above.
> If the wiki uses "modules" to refer to only pure Python modules, it
> is incorrect.
Then I suggest someone who knows about Python policy please
update the Wiki page to correct it.
>> 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.
Why do my packages need to change the dependencies, then?
Because when the default changes to 2.5, the dependency would have
to change yet again, for no changes in the package itself.
> If you always need Python 2.4, even when Python 2.5 is the default,
> then the python2.4-foo deps are still appropriate.
Right. But that is an answer to a different question.
>> 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.
Umm. That does not follow. My package foo, say, needs the
version 2.2 or 2.3. The default is version 2.3.
"Packaged modules available for the default Python version (or
many versions including the default)..."
It does seem reasonable to me that since 2,3 is the default
python version now, and my package is available for the default
python version, it should follow the directive in para one.
The semantics of "available for the default version" seem to
be very amenable for misinterpretation, so we should clarify it.
> 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.
I did not actually figure it out, there was a discussion on
IRC, and the alternate meaning was pointed out to me, and then it
did appear to be more reasonable.
I posit the wording is not adequate as it is, and should be
targeted for clarification.
>> 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.
Oh, I see. Say, there is an extension that implements a very
standard API for framework bar, which is packaged in package
bar. If this extension modules is used by a non-version-specific
script, the script can just import module foo, and not care that it
lives in a version specific dir.
Expanding on that thought, suppose I have python-foo version
1.0 that has been compiled with python 2.3. If the script uses
/usr/bin/python2.4, it won't be able to import my module --- unless
it asks for and gets a python2.4-foo. So, if the script uses a non
default version of python, or the extension module was compiled for a
non-default version of python, I must provide pythonX.Y-fooin case
someone somewhere has a script calling a specific version of python.
There is no actual harm in always providing pythonX.Y-foo for
all extentsion module packages (for all x.y supported and shipped
with the package).
>> 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.
Well, then, I shall just do my best to interpret how dh_python
behaves, and follow that in my packages. But reports would be
downgraded until we have a real python policy, since punting to
dh_python is clearly unacceptable for a policy specification.
Filing bugs on my packages asking me to use helper packages
shall be closed with extreme prejudice :)
manoj
--
Hoare's Law of Large Problems: Inside every large problem is a small
problem struggling to get out.
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: