Web lists-archives.com

Re: Do we want to Require or Recommend DH

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

> 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.

(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