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
