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

Re: dh_python and python policy analysis

Le mardi 01 août 2006 à 09:45 -0500, Manoj Srivastava a écrit :
> >> 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.

When there are both public extensions and public modules, both packaging
tools will handle them fine. With python-support, they are put
in /usr/{lib,share}/python-support/$package and will be symlinked
from /var/lib/python-support. The key point is to have them at the same
place, otherwise sometimes they won't work.

When there are only public extensions, packaging tools aren't needed at

> > 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. 

This is because python-central's internals use the control file.

>         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.

Both tools have the same needs but they do it differently. This is
because python-central relies on special fields in the control file
while python-support relies on its own files and directories.
     1. Information given by the maintainer about supported versions in
        the source package: python-central uses the XS-Python-Version
        field, while python-support uses debian/pyversions. For best
        compatibility, both tools are able to use each other's data.
     2. Place to store public modules: /usr/share/python-central
        vs. /usr/share/python-support/$package.
     3. Place to store public extensions: python-central keeps them in
        place, in /usr/lib/pythonX.Y/site-packages, while python-support
        moves them to /usr/lib/python-support/$package/pythonX.Y.
     4. Information stored about supported versions in the binary
        package: python-central uses XB-Python-Version - which is
        mandatory in this case - while python-support uses either the
        list of public extensions versions
        in /usr/lib/python-support/$package or
        the /usr/share/python-support/$package/.version file.
     5. Information about which private extensions to bytecompile:
        python-central will use all files ending in .py belonging to the
        package, while python-support lists directories
        in /usr/share/python-support/$package.dirs.

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

Python-support's README provides basic information on how to make a
package using it.
There's also a wiki page: http://wiki.debian.org/DebianPythonFAQ
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
  `-  Debian GNU/Linux -- The power of freedom

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Reply to: