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
all.
> > 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?=