[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Requiring Debhelper's dh in Some Circumstances

Hi.  Last month[1] I  started a discussion on whether we
wanted to increase the strength of our recommendation of the dh
sequencer from debhelper.
This message is a consensus call describing how I as the discussion
facilitator see the project consensus.
After the original discussion, I published the first version of this
consensus call on May 25.  Comments were due by June 16.


At the core of this discussion are a number of key issues that were
reflected in comments throughout the discussion.

* People who make changes across the archive such as enabling hardening,
  cross-building, bootstrapping, etc benefit significantly from more
  uniformity in packaging practices.  The time they spend working on
  packages that use dh is significantly less.  That is, people working
  on making Debian more reproducible benefit from when we adopt more
  uniform practices.

* People who spend time fixing the archive, fixing RC bugs, etc don't
  like to see churn in areas that are already working.  If it's working
  well, don't break it.  Developers doing NMUs do not always perform
  adequate QA of their changes.

* Traditionally we've valued respecting the maintainer's preference
  above most other factors.  In the limit, short of orphaning packages
  or removing maintainers, we don't actually have tools to get
  maintainers to do things they don't want to.  Per our constitution no
  one in Debian is obligated to do anything besides not stand in the way
  of others.  And yet this discussion is about pushing things towards
  uniformity and in a small way away from maintainer preference.


There are some exceptions where we think using dh is the wrong choice;
see below.  We have a strong consensus that unless there is some
reasonable reason to do something else, new packages should use dh.

There's a weaker consensus that existing packages should use dh, but
migrating working packages to use dh is often not the best use of our
resources and can be harmful when it introduces bugs.  A number of
people spoke against choosing dh for existing packages.  I looked at the
reasons expressed.  A number of these focused on concerns about
introducing bugs.  When I read through all the messages I think it was
fair to interpret a lot of these concerns as asking us to be careful
about how we spend our resources.  It is generally harmful to convert a
package to dh without adequate testing.  It often makes sense to spend
time on something other than converting working packages to dh unless
doing so fixes something else or makes something easier.

But if a maintainer asks if in an ideal world should their package use
dh, the rough consensus of this discussion is that unless there is an
adequately justify reason to do something else, "yes".

After the initial consensus call, a few people raised additional
concerns about this recommendation.  No new issues were raised; the
points raised during final comments had been adequately addressed during
the body of the discussion.  The comments were not numerous enough to
make me think I had misjudged the community's values when considering
the various trade offs.  In addition, there were also new comments in
support of more uniformity in packaging.

Reasons to Do Something Else

This is not a complete list of reasons not to use dh.  That list will
likely evolve over time, but here are reasons identified in the

* If you're actively working on something new, innovation is still
  something we care about.  We're not trying to close down development
  of the next great thing.

* Cdbs has a few features that dh doesn't have.  The Haskell tools in
  cdbs ar critical to our current Haskell infrastructure.  Cdbs flavors
  don't seem to have a dh analogue.  For examples compare
  n/rules .  If cdbs is doing something for you, then it probably makes
  sense to stay with it for now.  But it sounds like there's discussion
  of retiring cdbs longterm.  So if you're using cdbs for things dh is
  perfectly good at, the cdbs exception is much weaker and possibly may
  not apply.

* Consistency with teams.  If your team is using something else, then it
  might be worth having a discussion within the team about whether
  that's still the best choice, but consistency within teams is

* We need to go back and check if there are any bootstrapping concerns
  that should affect build system decisions for specific packages.  See
  my next steps at the end of this message.

There was strong consensus that we should have a lintian tag that can be
overridden to indicate why a package is not using debhelper.

I think there is rough consensus (although rougher than some other
things) that individual maintainer preference is not in and of itself a
justification for not using dh.  That is, I think the people  arguing
for how using dh made their jobs either in making large changes to
Debian made a better case than those arguing for maintainer preference.
However Mo Zhou reminded us that we need to keep things fun.  If a
maintainer really wants to use something other than dh there's a good
chance that there is some underlying requirement dh is not meeting.  And
that probably is a legitimate reason not to use dh.

we're not coming after people with pitchforks if they don't use dh.  It
might simply mean their packages have a bug.  It certainly doesn't mean
they are obligated to fix that bug, although best practice in our
community is to work with submitters of patches to review those patches.

Again there were some dissenting final comments, but my reading is the
consensus stands.

Is Not Using DH a Bug?

It's certainly not an RC bug.  There was some talk of it eventually
being an RC bug if a new package doesn't use DH (and doesn't fall under
an exception).  I don't think there's consensus for that today.

It's obviously not a bug if there is a reasonable reason not to use dh,
but once the lintian tag exists, overriding that tag sounds to me like
best practice to document the exception.  (Presumably for things like
Haskell we'd want Lintian to be smart enough to figure that out on its

To some extent I'm extrapolating from implications of the rest of the
consensus call for the rest of this section.  There was some discussion
of whether not using dh should be a normal bug, but the comments about
that were inconsistent with the rest of the discussion.  But if the
consensus call above that existing packages (absent adequate
justification) should use dh stands, that's approximately the definition
of a normal bug.  So my reading is that absent adequate justification,
not using dh is a normal severity bug.

It doesn't mean you should file that bug and it doesn't mean that you
should go fix that bug.  We definitely didn't get the kind of support
we'd be needing for a mass bug filing or anything like that.  It
wouldn't serve a point.  This isn't atypical.  There are a lot of things
lintian flags that are technically bugs, but we wouldn't want to mass
file all lintian tags (even if we could filter out false positives) as

This paragraph is very much my interpretation.  I'd personally say that
if you're going to file a bug that a particular package doesn't use dh,
have a good reason and document it in that bug.  Your reason might be "I
want to contribute; I'm willing to dedicate time and updating the
packaging would make it much more appealing to work on."  Often your
reason will be that there's some other problem, migrating to dh will fix
that problem, and between the time you're willing to spend and the time
you hope the maintainer will spend it's worth doing a good job of that

My interpretation of our standard practices is that maintainers have
wide discretion in which bugs they work on.  That said, if someone
submits a patch, it's good if you review it.  It's fine to ask them to
do the necessary testing work and it's fine to hold them to the same
high standards that you hold yourself to.  If they are less experienced
with the package it might make sense for them to do tests that make up
for that experience gap.  None of this  changes any of that or asks
maintainers to treat bugs about dh differently than other bugs.

Next step for this section is to have a policy discussion; see below.

Best Practices for Testing DH Conversions

* Run a debdiff of the binaries to see what has changed

* Use diffoscope

* Run autopkgtests

* Test piuparts

Generally look at the packaging and explain any changes carefully.

So I should Go NMU the Archive to DH


We had a long discussion of NMUs and dh that was probably my fault and

Through a round about set of messages we seemed to come to a consensus
that is roughly the same as our existing NMU policy.

I don't see a consensus to change how NMUs regarding dh are handled.

Generally doing an NMU to change packaging style is not a good idea.
There are cases where it might be appropriate.  Feel free to read the
longer discussion and to look at discussions of NMUs in Developer's

Next Steps

I will go open a bug on debian-policy asking the policy editors to
document this consensus following their standard process as the
debian-policy lists sees best.  Some early discussions with the policy
editors suggest they have ideas and are well up to the challenge of
proposing something for the community to consider.
Thanks Russ and Sean!

I'll see whether the Lintian maintainers need a bug filed and file one
if necessary.

I'll make sure that people involved in bootstrapping have an opportunity
to comment in the policy discussion if they have input.

A Closing Word from Our Sponsors

Thanks everyone for helping out with a great discussion.  I hope that we
can use this approach for exploring other issues and reach similarly
productive outcomes.

While I'm writing to -devel-announce, I could use your help with another
matter.  In preparation for a meeting with the Antiharassment team,
account managers, former DPL and myself, I am soliciting feedback on how
well the Antiharassment team is meeting the project's needs.  I've
received very little feedback from people who have actually interacted
with our antiharassment team either as reporters or respondents.  I
regret sticking something this ephemeral onto a long-lived message, but
I'd regret a second post to debian-devel-announce more.  I could really
use your feedback; see
https://lists.debian.org/msgid-search/tslmuivstkr.fsf@suchdamage.org for
my questions.


Sam Hartman
Debian Project Leader

Attachment: signature.asc
Description: PGP signature

Reply to: