Web lists-archives.com

Do we want to Require or Recommend DH

As promised, I'd like to start a discussion on whether we want to
recommend using the dh command from debhelper as our preferred build

As we can see on https://trends.debian.net/#build-systems a majority of
packages already use dh.  So what would it mean to recommend dh?

The New Maintainer's Guide [1] already is based around debhelper and dh
and effectively recommends it strongly.  So it wouldn't mean that.

  [1]: https://www.debian.org/doc/manuals/maint-guide/

I guess at a simplest level, this would be validating the assumption
that Lucas made behind trends.debian.net that not using dh is a "package
smell," that maintainers should think about fixing.

But I think what we're really talking about is whether maintainers
should be expected to apply well-written patches to convert a package to
using dh.  That is, is not using dh a bug.

And at some level I think we're asking whether it is appropriate to NMU
a package to convert it to dh.

Today at least I don't think we're talking about making not using dh an
RC bug.  It would not make a lot of sense to me to start there.


Even if we do decide that not using dh is generally a bug, there are
doubtless some exceptions.  If I remember correctly at least one of the
language-specific packaging approaches is based around something else.

There may be some classes of packages where dh doesn't make sense today.

As part of this discussion I hope we will collect a list of exceptions
where dh is not the right answer today.

Why Would we Want This?

So, first, a lot of people have argued that dh makes packaging simpler.
I've certainly found that to be true and use dh for any new package I

That alone might be an argument for no dh being a package smell, but
probably not a good argument for making not using dh a bug.  If dh makes
your packaging simpler, that alone is probably sufficient motivation to
adopt it where appropriate.

There's another argument though.  Using dh might make things easier for
others making changes to your packages.  It makes it easier for us to
apply changes in things like how init scripts are called across the

Andreas Tille's explanation (quoted below) is typical of what I've heard
in this area.

>To come back
>to the question:  I'm positively convinced that we should strive to
>unify our packaging as much as possible and in terms of d/rules file dh
>is obviously the default we should pick.  I'd go that far that lintian
>should issue some warning at "pedantic" level if there is no comment:
>"I'm not using dh because ... ".  In other words:  Use dh in debian/rules
>should make it into policy.

>The rationale is that dh makes it extremely easy to understand other
>d/rules files.  Specifically in freeze like now it is easy to touch
>other peoples packages (just done this several times in the last weeks
>and luckily close to all used dh).  Its the point of teamwork (and I
>consider all people touching official Debian packages as a team) to make
>things simple for team mates.  I consider it a valid request to every
>single maintainer to respect that other people have good reasons to
>change her/his package.

Evolution Towards a Team

I'd like to call out one specific thing from Andreas's quote and the
general argument.  It's the belief that we've reached a point where in
some cases uniformity is more important than maintainer preference.

If true, that would be a big change for our community.  We've spent many
years making it easy for maintainers to have a great deal of autonomy.

I don't see that going away, but Andreas and others seem to be arguing
that once we've found a good solution we should encourage uniform
adoption to make it easier when we have to work on others' packages.

Why Not Make this Change

The biggest argument I've heard against changes in this area is that
moving towards dh and debhelper will introduce bugs.
Like any significant change it requires effort both for development and
for testing.

One maintainer claimed that even if someone else wrote the patch it
wasn't worth their effort to validate for a package where the existing
build system was already working.

Your Thoughts

so, what do you think?

I'll start with a general discussion but unless the answers are obvious
follow up with some specific questions in a few days.

Thanks for helping us explore this issue,


Attachment: signature.asc
Description: PGP signature