Future of dh_python
Hello everybody,
as you might have seen on Joey's blog, he expressed some wishes about the
future of dh_python:
http://kitenet.net/~joey/blog/entry/proposed_transition_plan_for_removal_of_dh_python_from_debhelper.html
As I can understand him, we really should respect his wish. If Matthias agrees,
I can extract the "dependency" generation code from dh_python and create
a little perl library that would be included in the python package
(or python-dev) and that would be used by dh_pysupport and dh_pycentral.
I can also prepare patches for dh_pysupport/dh_pycentral.
dh_python would be modified to support only v1 mode (with a big
deprecation warning) and would be no-op if debian/pycompat was 2
(including the implicit pycompat=2 set if the XS-Python-Version header is
here).
python-support/central will have to depend on the new debhelper to avoid
generating dependencies twice if dh_python is invoked (as is currently
the case for most packages).
The new debhelper will have to be uploaded together with the new
python-support/central to avoid any problem (If it is uploaded before,
some packages may not have dependencies at all. If it is uploaded after,
python-support/central won't be installable.)
As I volunteer(ed) to maintain this part of the code (dependency
generation for dh_py*), I suggest to start using the pkg-python project
(and its associated SVN repository, or whatever VCS suits you best,
Matthias) so that I can directly maintain this part of the code in the
package. If you don't have time for the initial import and all, just
let me know, I can add myself to the project and setup things for you.
Now replying to the problems Joey expects:
> dh_pthon supports params for passing additional module directories.
> dh_pysupport does too, but it seems that dh_pycentral does not. Need to
> check if this means that noone using dh_pycentral can use it with
> non-standard directories, so none of them pass directories to dh_python.
dh_pycentral scans all the directories by itself so it shouldn't be a
problem for byte-compilation. For the dependency generation, we need to be
able to know that a .so is a Python extension module and not something else
and so we rely on this parameter to know that any .so in the directory is
effectively a python extension module.
I heard that python-support implemented something else (with objdump) to
assert that a .so is a python package.
In any case, it would be no problem to add the same parameter to
dh_pycentral or to improve the way we detect the python extension module.
> dh_python has -V and -X flags that affect its behavior and the other two
> programs would not have access to this information.
> * I doubt that -X is used widely. Grep.
> * -V is a redundant interface, since it does something approximating
> what debian/pyversons does. So things should be able to switch to the
> other interface, except in edge cases (although IMHO it's not an
> appropriate interface for a debhelper program), and for the edge
> cases, -V could be added to the other two programs.
Exactly, we should get rid of the "-V" parameter completely. -X support has
been added during my NMU as it was a wishlist that I found useful (so -X
isn't widely used).
> It's possible that someone might set dh_python's -n flag but not also
> set it on their call to dh_pycentral or dh_pysupport. Can't imagine why
> though.
I don't see any reason either. No worry here.
> Not all packages use the new python policy yet. For example, debconf
> doesn't. I'm not sure if that's a bug or not. One alternative would be
> reverting dh_python to the pre-NMU version (plus a small shim to make it
> a no-op if it detects the new policy), to avoid breaking such packages
> until they transition.
Indeed, for me it appears unavoidable (cf my suggestion above).
And we must also coordinate the upload of the new version of the
packages.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: