Re: Do we want to Require or Recommend DH
On Monday, May 13, 2019 8:33:44 AM EDT Sam Hartman wrote:
> 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
> system.
>
> 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.
Absolutely not. A likely bug inducing drive-by NMU is not helpful.
>
> 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.
>
> Exceptions
> ==========
>
> 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
> make.
>
> 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
> archive.
>
> 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,
>
> --Sam
I think for new packages (with the exception of new packages maintained in a
team that has a different pattern), it's not unreasonable. When starting from
scratch, dh is almost certainly no harder and usually easier than traditional
debhelper or other approaches.
For existing packages, not so much. There are probably packages left that
would be trivial to convert, but I expect that most of those have been taken
care of already. For complex packages, this can be really hard to get right.
In the experiences I've had, converting packages that I maintain and have a
great deal of familiarity with is still fraught with error.
For really complex packages, they are going to be hard for someone not
familiar with the package to modify regardless of dh/debhelper. My guess is
that if we try and push this direction the effort will mostly be spent where
there is the least potential for gain and the most risk of regressions.
For improvement of existing packages, I think there are better things to
expend resources on.
Scott K
Reply to: