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.
Design
------
* 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!
Technical
---------
* 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.
Social
------
* 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
started.
* 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.
Policy
------
* 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
something.
* 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.
Thanks,
Guillem
Reply to: