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 /\./\ : :' : [EMAIL PROTECTED] `. `' [EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée