RFC: debhelper v2

[Joey Hess <joey@kitenet.net>]

It's become clear over the past half year or so that some of the historical
baggage debhelper inherited from debstd is holding it back. So I'd like to
start revamping debhelper and getting rid of these historical
inconsitencies, to make debhelper programs as clean and as easy to learn as
possible.

But now that we have a large base of packages that depend on the current
debhelper behavior, I have to make sure that those packages continue to
build with any changes I make to debhelper.

I think I have a solution - starting with debhelper version 2, debhelper
will continue to behave as it does now by default. If a special environement
variable, DH_COMPAT, is set to 2 or above, it will change over to using the
new, clean functionality. This will of course be accopmplished easily by
setting the variable at the top of debian/rules.

So what remains is figuring out what to change. I'm looking for feedback on
this, so if some aspect of debhelpor has bothered you but couldn't be
changed without breaking backwards compatability, now's the time to bring it
to my attention. Here's some things I could change:

* Standardize on the name used for the temporary build directory of a
  package. Currently it's debian/tmp/ for the first package and 
  debian/<package>/ for other packages of a multi-binary package. I'm
  considering debian/<package>/ for all packages, or perhaps
  debian/tmp/<package>/ or perhaps debian/<package>-tmp/ . Of course making
  this change means a certain amount of changes will be needed to make any
  package work with v2.
  
* debian/README should be installed as /usr/doc/<package>/README in native
  packages, and as README.Debian in non-native packages. This is consitent
  with the handing of debian/TODO and debian/changelog. (#34628)

* dh_installmanpages needs to be made much smarter, or much stupider. I
  prefer making it stupider, it's much too DWIM-ish already.
    smarter - parse .TH lines in manpages, look at binaries with names
              matching manpages do anything else possible to get manpages
              installed into the right directory and section. (#16933, #17061)
    stupider - stop automatically finding manpages, require the user to tell
               it what files are man pages and where they go. Much more
               consistent with other debhelper programs.

* dh_movefiles should delete empty directories after it's moved all files
  out of them. (#17111)
  
* dh_movefiles should use a name other than debian/<package>.files for the
  list of what to move, because it can't use debian/files for the first
  package, since that file is already used elsewhere. I'm thinking
  debian/<package>.move

or

* I've observed that large multi-binary packages end up with an unruly
  debian/ directory with all the <package>.* files in it. It may make sense
  to make debhelper use debian/<package>/* instead. Of course this requires
  that directory is no longer used as the temporary build directory.
  
or

* Debhelper could be changed to look at only debian/<package>.<foo> instead 
  of looking at debian/<foo> also as it does in some cases now. The advantage
  is just a simpler UI, you don't have to be concerend about what's the first
  binary package listed in the control file anymore. A disadvantage is longer
  filenames. This could be combined with the subdirectory idea, giving us
  debian/<package>/foo, but that seems a little silly if your package only
  generates one binary package.

Well I'm looking foward to some comments.

-- 
see shy jo