On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote: > 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.
Its the first time that I hear criticism about d-shlibs usage and I'm fine with discussing this but I'd prefer not to spoil the current thread. > 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. I for myself prefer to debug code based on the same tool set. > >... > > 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 I agree that these are potential sources of bugs. However, I do not see much evidence that if an NMUer / team member does any edit on some d/rules file would be different to the cases above. > 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. +1 (But I do not see any argument against using dh here) > 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. NMUers should do debdiff - no matter what change was done. And yes, it happened also to me in the past once or twice that I uploaded an empty package or package missing some files. I do not remember whether it was connected to a change to dh or not ... but mistakes happen. The fact that we might end up with broken NMUs is IMHO orthogonal to any cdbs to dh change. > 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. As far as I understood the point of the discussion is that we want to get the whole archive more uniform to reduce the potential causes for bugs *in* *the* *future*. This might come at the expense of some bugs when doing so and IMHO the beginning of a release cycle (= after Buster release) is a sensible point in time to do so. BTW, Adrian, thanks for all your patience and bug fixing at an extremely high rate. It is really welcome and appreciated and I think its a good chance to mention this explicitly here. Kind regards Andreas. -- http://fam-tille.de