Web lists-archives.com

Re: Do we want to Require or Recommend DH

On Mon, 2019-05-13 at 08:33:44 -0400, 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.

So, here's my take on this. I do use debhelper everywhere, I also use
dh mostly at work, and personally perhaps when it requires no overrides
or very very few of them, or as a replacement for equivs. I do not have
any major problem with debhelper nor dh, I find *both* styles more
pleasant than a hand-crafted debian/rules, but from here it seems like
some in this thread are oblivious to problems with its usage.


* debhelper design's principle has been to be a thin layer, most of the
  heavy lifting used to get delegated to other tools and/or lower-layers.
* Both cdbs and dh are based on similar principles, which is to cover as
  much as possible automatically, and override/diverge on the specifics.
  The problem I see though is that they are implemented inside-out, and
  that is one big reason both end up being so much more complex than they
  need to be. This is obviously not a problem of their making!
* Both debhelper and cdbs have a concept of a versioned API. Which is
  nice because it makes it possible to introduce staged changes that
  could otherwise break the world. debhelper seems to be more strict
  about adhering to its API though, and it has proper documentation
  compared to cdbs which does not, which I think is the main reason I
  always found cdbs unappealing as you need to read its source code
  making its entire implementation its interface. This made me realize
  the same applies to dpkg's make fragments (which tend to be used with
  dh too), so I'll be adding man pages for those during 1.20.x. :)
* dh uses an implementation hack to be able to introspect on make.
  This is something that has always slightly put me off. I'm counting
  the days until I can remove a similar but way less clever hack in
  dpkg-buildpackage that tries to introspect on the build targets!


* Not so simple:
  The proclaimed simplicity is only apparently so. Using dh might result
  in shorter debian/rules files, it might (perhaps) result in debian/rules
  listing only the exceptions; all these are one side of simplicity. At
  the same time it makes things more complex because it's yet another
  layer, an abstraction which hides (at the source level) implementation
  details, which you still need to know when having to modify the
  packaging; you need to know how each of dh, debhelper, the various tools
  debhelper uses, make, shell, the upstream build system, the source format
  and patching, the dpkg toolchains, etc. all work, and how they interact.
* Complex is still complex:
  For simple cases, it can indeed be very simple and obvious, for complex
  cases with tons of overrides and make variables, many times it does not
  seem better than an unrolled debhelper debian/rules file.
* Not so uniform:
  Uniformity even with required usage of dh (is not and) would not be
  as uniform as people might want to believe. This is still dependent
  on other helpers used (and which, say dh-exec), on make/shell style,
  on whether you implement the logic in make or shell or an external
  package-specific program (in whatever language) that you call from
  debian/rules, etc.
* No free global change:
  Makes pushing global changes somewhat easier? Yes, but also taking into
  account that any such change in most cases will still require a compat
  level bump, the maintainers making sure it works, and that any override
  has the potential to disable those changes. The main advantage is that
  it might remove the load on maintainers having to recall to do that
  specific change, they just need to make sure it works. It might also
  play in the other direction, with maintainers missing that they need to
  check for these changes "because dh takes care of everything". But this
  just enables a "passive deferred transition", and people that want to
  see a transition done *now* still might need to do tons of work.


* It has already naturally gained majority mindshare, because in most
  cases and for most people, it's obviously better than the alternatives,
  I expect this will keep going as debhelper/dh improves, why the need
  for a forced push then for the people who are not yet convinced? This
  always looks suspect to me. For cases like this, I always find it's
  better to convince people with good arguments or better implementation
  and/or documentation, not with force, but dunno.
* A hard requirement means innovation might be thwarted, even if
  innovation is excempt, it would require people to justify beforehand
  (either publicly or to themselves) whether the new solution is going
  to end up being really better than the status quo even before it's
* Optimizing for NMUs seems wrong, we should be optimizing for long
  term maintainership. Something that can only be sustained by NMUs has
  a high chance of being orphaned and RMed from the archive. If it gets
  orphaned/adopted the new maintainer(s) can always switch to whatever
  anyway. Alienating productive and engaged maintainers in the name of
  the "collective" does not seem wise. For packages I require and I'm
  not able or willing to maintain, if the option is between them using
  an uncommon packaging style, or them being unmaintained or possibly
  removed, I'd pick the former any day. Neither potentially losing
  contributors over this seems wise.


* What does truly using dh mean? Given that dh and debhelper original
  principles were to be very thin layers? Is using many external
  Makefile fragments still using it? Is using many external helper
  tools explicitly still using it? Is overriding most of the dh
  sequence/commands still using it? Codifying the properties people
  seem to want in policy for something like dh, seems between hard to
  close to impossible.
* debhelper is a thin layer that implements policy, requiring it in
  policy feels very wrong (between tautological and a layer violation).
  Mentioning or recommending it seems fine though.
* Requiring a list of undetermined and open-ended exceptions for when
  dh is not appropriate looks like the wrong way to standardize
* Already recommended almost everywhere (docs, dh-make*, mentors,
  prevalent packaging style, word of mouth, etc.).

So, while I think debhelper and dh might in general make things easier
and simpler, and I personally prefer them (depending on the context) to
other packaging styles, I think (obviously with a very biased PoV) "they"
are still missing the point. And true clarity and simplicity can only be
achieved by rethinking some of the packaging foundational concepts we
use, and by trying to push stuff down the layers. And by more clear,
structured and holistic documentation too.