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

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.  

        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

        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

        Pointers to any packaging guyides using either tool would also
 be appreciated.

If you can count your money, you don't have a billion dollars. Paul
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: