Web lists-archives.com

Re: Do we want to Require or Recommend DH




Quoting Adrian Bunk (2019-05-14 10:11:46)
> On Mon, May 13, 2019 at 11:08:21PM +0200, gregor herrmann wrote:
> > On Mon, 13 May 2019 22:22:32 +0300, Adrian Bunk wrote:
> > 
> > > 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.
> > 
> > In my experience ancient debian/rules runes are also a cause for
> > repeated RC bugs and the need for NMUs.
> > 
> > Real life example:
> > https://tracker.debian.org/media/packages/libm/libmp3-info-perl/changelog-1.24-1.2
> > 
> > Both RC bugs wouldn't have happened with dh(1); and the second NMU
> > wouldn't have been necessary if I had switched to dh(1) in the first
> > one.
> 
> How well are you testing such conversions?
> Based on work I've seen from you I'd guess your NMU would be better than 
> average. Unfortunately this is not generally true.
> 
> Based on what enters the archive, "debdiff between old and new package" 
> already seems to be something that many people are not doing - then
> cleaning up after mass-NMUs would be much work.
> 
> I have even seen maintainers blindly replacing a complex old
> debian/rules with the dh 3-liner, and all the bugfixes and
> workarounds in the old one were bugs again.
> 
> To show the quantitative side of my argument:
> 
> The default change to parallel building in dh compat 10 alone has caused 
> a three digit number of RC bugs, popping up at a pace of 1-2 RC bugs
> per week for several years.
> 
> The problem is that anything that works for only 99% of all packages
> results in such a high number of new bugs.
> 
> Parallel build bugs slipping through an upload can happen,
> but maintainers not going through the upgrading checklist
> and running debdiff between old and new packages as well
> as testing them when doing dh compat bumps is harder to
> excuse - and in practice this does happen.
> 
> There is no perfect solution here

What makes reproducible-builds not the perfect fit for this?

Whenever I converted a package to dh or bumped debhelper compat level, I always
checked whether the produced binaries were bit-by-bit identical to the ones
before.

Are there many errors that I would be missing by relying on reproducibility
results?

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature