Re: dh_python and python policy analysis
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
Note that these two contain the same modules. The /usr/share directory
isn't read by python, only the generated tree in /var is.
> 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. XB-Python-Version is a way to generate metadata but it
isn't necessary either. The same applies to all you've written about
> 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:. However, no
packaging tool is currently able to generate this information.
> 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.
> 188.8.131.52. XS-Python-Version:
> This is a list of python versions supported by the package. This field
> can be a single version, or a set of ranges. This should be set to the
> list of python versions that the script can support, or "all". If a script
> invokes /usr/bin/pythonX.Y, then XS-Python-Version should be set to X.Y.
If dh_python isn't able to parse these headers (as it used to do in the
"old" policy), I consider it a bug.
> 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.
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.
.''`. Josselin Mouette /\./\
: :' : email@example.com
`. `' firstname.lastname@example.org
`- Debian GNU/Linux -- The power of freedom