Re: dh_python and python policy analysis
On Tue, 01 Aug 2006 09:55:39 +0200, Josselin Mouette <joss@debian.org> said:
> Le lundi 31 juillet 2006 à 21:10 -0500, Manoj Srivastava a écrit :
>> Public modules are available for use in other Python scripts or
>> modules using the import directive. They are installed in one of
>> the directories
>>
>> /var/lib/python-support/pythonX.Y /usr/share/python-support
> Note that these two contain the same modules. The /usr/share
> directory isn't read by python, only the generated tree in /var is.
Thanks, I'll explicitly make a note of that in that section.
>> The new python policy places certain requirements for packages that
>> contain Python bits.
>> 2.1. XS-Python-Version: 2.2. XB-Python-Version:
> These two are by no means requirements. XS-Python-Version is only a
> way to tell the packaging tools which versions to use, but you can
> also use debian/pyversions which is the recommended way as it
> doesn't pollute control files.
Hmm. I'll remove mention of it, then. How exactly one
invokes packaging tools should not be in this document; which is
trying to be a specification more than a packaging guide.
> XB-Python-Version is a way to generate metadata but it isn't
> necessary either. The same applies to all you've written about these
> fields.
The draft Python policy states:
,----[ Section 2.3 ]
| Your control file should also have a line:
| XB-Python-Version: ${python:Versions}
| The python:Versions is substituted by the supported Python versions of
| the binary package, based on XS-Python-Version. (If you are not using
| dh_python you will need to handle this substitution yourself.) The
| format of the field XB-Python-Version is the same as the
| XS-Python-Version field for packages not containing
| extensions. Packages with extensions must list the versions
| explicitely.
`----
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html
Is the draft policy incorrect in this case? (The directive is
a should.)
>> 2.3. Depends:
>>
>> Packaged modules available for the default Python version (or many
>> versions including the default) 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.
> For the packages to be consistent, the package should depend on all
> pythonX.Y-foo for the versions listed in Provides:.
I'll add this note, thanks.
> However, no packaging tool is currently able to generate this
> information.
Well, that's all right. First we decide what is the right
thing to do, then we provide tools. Packaging tools are there to
assist us, after all, not to limit us.
>> 2.4. Provides
>>
>> Packages with public modules and extensions should be named, or
>> should provide, python-foo, if the package contains an extension
>> for more than one python version. Also, for every version of python
>> supported the package should provide pythonX.Y-foo packages.
> In fact, it should not provide this unless it has correct
> dependencies on all pythonX.Y-bar - but everyone is doing this
> wrong.
Thanks, I'll try an go through to document to ensure I have
the specifications done correctly.
>> 3.1.5. Public Extension
>>
>> Public extensions should be packaged with a name of python-foo,
>> where foo is the name of the module. Such a package should support
>> the current Debian Python version, and more if possible.
> Maybe a word on how public extensions and public python modules
> interact would be nice.
I'd appreciate any suggestions.
> Generally speaking, I don't find this document useful to the package
> maintainer. It focuses mostly on python-central's internals, which
> don't need to be fully understood by the maintainer, and which
> aren't useful if you don't use python-central.
It is curious that you say that, since I have not yet looked
at pycentral, what you see here is derived ojnly from reading the
draft policy in detail and then reverse engineering what dh_python
does.
The motivation for this exercise was for me to be able to
understand what the desired requirements of the new python policy are
well enough to comply with them -- I prefer not using packaging tools
if I do not understand what they do and can't do it independently.
At this point, could you please point out the salient points
of divergence between python-central and python-support? From what I
am given to understand, these take public pure Python modules and
byte compile them for every avaialable version on the taarget
machine, and recompile as needed when new versions of python become
available.
Pointers to any packaging guyides using either tool would also
be appreciated.
manoj
--
If you can count your money, you don't have a billion dollars. Paul
Getty
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: