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

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

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

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

>       3.1.1.1. 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        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
   `-  Debian GNU/Linux -- The power of freedom



Reply to: