I am not happy with dh_pthon
in the current state that it was (NMUed
into) debhelper. It is preventing me from feeling good about or
generally maintaining debhelper. This is a plan for fixing that.
- Transform dh_python into a perl module or program by some other name and possibly different interface, and put this in some other package(s).
- Modify dh_pysupport and dh_pycentral to call above so they take over dh_python's part of the work.
- Reduce dh_python to a no-op warning script and put on deprecation track for removal.
- Add a regression test to debhelper that fails if any debhelper script exceeds 150 lines, excluding POD docs. (Done in svn)
If at any point the python maintainers find an approach that does not invole multiple competing implementations and that is either simple or has the complexity encapsulated into some other program, I can add back a dh_python.
Until then the current mess will be Not My Problem.
- Be much, much, much more cautious accepting niche programs into debhelper in the future. :-(
Possible technical complications:
- 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_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.
- 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.
- 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.
Add a comment