On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote: >... > 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. >...
Based on this rationale, Andreas should stop using d-shlibs. Weird tools on top of dh are not that different from using a weird buildsystem when debugging other peoples packages, and d-shlibs is something I've seen involved in bugs more than once. >... > 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? >... > As part of this discussion I hope we will collect a list of exceptions > where dh is not the right answer today. >... What is actually the problem that needs legislating here? For any newly packaged (and often also adopted) package that can be packaged with the trivial dh 3-liner this is already being done, with exceptions within the margin of error. When you debug for the first time a non-trivial problem in a complex package like src:gcc-8 or in a package in an ecosystem like Haskell you can easily spend hours just for figuring out what is actually going on or how to pass additional flags. Whether or not the build machinery is using dh is not a big difference when you have to understand what is actually going on. >... > And at some level I think we're asking whether it is appropriate to NMU > a package to convert it to dh. >... Common causes of broken packages in the archive include: - dh compat level bumps - conversion of debhelper using packages to the short dh form - conversion from other build systems to dh It is already a real problem when maintainers are bumping dh compat levels without checking very thoroughly before uploading that this didn't cause any regression - a dh compat level bump is a breaking change and should not be done without due diligence. And we do get broken packages packages uploaded where the NMU of a build system change (e.g. cdbs to dh) resulted in an empty package - whoever uploaded such a package clearly didn't even do basic checks. In my experience, keeping existing packages at exotic build systems or ancient dh compat levels causes fewer problems than people trying to change that just for the sake of it. > --Sam cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
