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. 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
signature.asc
Description: PGP signature
