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
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
Reply to: