debhelper

The new debhelper udeb support is reminding me of the early days of debhelper, when rules file after rules file was converted to something much simpler, and the experience of doing so feed back into debhelper development to make it better an better. I have so far only converted a half a dozen, but the urge is there to change over the whole d-i tree.

One thing that I have realized as a result of this is that I've perhaps gotten too conservative about what I let into debhelper. I rejected the original request for the udeb support; I often let new utilities sit in the BTS for up to years, waiting for some small problem in their design to be resolved (dh_installinfo), or just because I am reluctant to let them in. Partly that's a good thing, since I am still dealing with some mistakes made in the early days (dh_md5sums, dh_du, dh_installmanpages). Partly it's a bad thing because this has resulted in quite a lot of dh_* programs being relegated to packages outside of debhelper (dh_installxmlcatalogs).

Partly this is a result of debhelper being a mature project now. There is a lot of pressure not to break backwards compatability, and not to break stuff (too badly/often). So it's not suprising to see a certian shift of interest/development to younger projects, like cdbs.

Anyhow, it's a tightrope to walk, and I've made some good decisions too. The debian/compat stuff allows me to retain backwards compatability while still exploring better incompatable behaviors. Outsourcing most of the maintenance of parts of debhelper (dh_python, dh_perl) to those who are best equipped to maintain them, while keeping them in the package has also helped.

Going forward I will try to be more open to new ideas and new utilities in debhelper, and I have a glimmer of a possibly correct way to handle the long-promised OO rewrite, if I can ever find the time for it.