Do we want to Require or Recommend DH

classic Classic list List threaded Threaded
116 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Adrian Bunk-3
On Tue, May 14, 2019 at 10:27:45AM +0200, Johannes Schauer wrote:

> Quoting Adrian Bunk (2019-05-14 10:11:46)
> >
> > 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.

Don't assume everyone follows the same high standards as you do.

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

The parallel build issues I mentioned might be missed,
but this is more exceptional.

dh compat 12 defaulting to dh_dwz might make the -dbgsym packages
different, and other intentional differences might exist.

> Thanks!
>
> cheers, josch

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

Reply | Threaded
Open this post in threaded view
|

d-shlibs (Was: Do we want to Require or Recommend DH)

Andreas Tille-5
In reply to this post by Adrian Bunk-3
On Tue, May 14, 2019 at 01:12:17PM +0300, Adrian Bunk wrote:

> On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> > On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > > > >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
>
> It is fine in the current "maintainer can do anything" world.

Hmmm, I don't get it:  I'm using dh and in addition I'm using a tool
that enforces library packaging policy.
 

> > and I'm
> > fine with discussing this but I'd prefer not to spoil the current
> > thread.
> >...
>
> It is actually part of it, due to:
>
> >...
> > 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*.
> >...
>
> If this is the point, then weird tools on top of dh are part of the
> problem just as weird buildsystems are.

d-shlibs is not really on top of dh.  Its invoked with override_*
and thus clearly separate from dh.
 
[Haskell-example snipped since I think this was discussed somewhere
 else.]

Kind regards

      Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Andreas Tille-5
In reply to this post by Ben Hutchings-3
On Tue, May 14, 2019 at 10:38:06AM +0100, Ben Hutchings wrote:

> On Tue, 2019-05-14 at 11:07 +0200, Andreas Tille wrote:
> >
> > Can you give an example for a package that has a non-dh rules file
> > "working for years" that gives as a result a package with no lintian
> > warnings without changing this d/rules file?
>
> linux is one.
>
> I did a lot of work to address lintian warnings last year, and most of
> that did not involve debian/rules*.
 
Please call me over-picky but without checking the history is your
"most" not a sign that there is at least one change to d/rules which was
needed to fix some lintian issue.  I do not want you to change linux
d/rules file and I think it is pretty safe from beeing NMUed just to
switch to dh.  My point was that I doubt that any "working for years"
d/rules has no lintian issues.

Kind regards

     Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Ian Jackson-2
In reply to this post by Sean Whitton
Sean Whitton writes ("Re: Do we want to Require or Recommend DH"):

> I agree with Scott's emphasis on the distinction between new and
> existing packages.  Perhaps application of the distinction could be
> extended: perhaps there are other things that we could require of new
> packages, while creating no expectation that these requirements be met
> of older packages.
>
> In general, if a policy requirement or convention should apply to new
> packages, then it should apply to existing packages, too.  But
> specifically where applying the requirement to an existing package is
> hugely more work than applying it to a new package, perhaps the
> requirement ought to be limited to new packages alone.

There is a big distinction between recommendations which directly
affect the functioning of the binary packages, and recommendations
which make future development easier.

For the latter - and use of dh is an example - it makes a lot of sense
to make the recomendations stronger for new packages.

I also think it would be very valuable for policy to recommend things
like this as the usual case, without mandating them.  If for any
reason the maintainer doesn't want to use dh, then they can leave a
wontfix bug open (or something) to document the reasons.

My own anecodote:

Last year I converted src:xen to dh from the previous baroque system
(which I think was based on a clone-and-hack of the machinery in
src:linux.)  The result is massively better.

But it was serious work to repeatedly debdiff the results, review each
individual weird thing and decide whether to keep it, try to reproduce
its effects with a dh override or whatever, etc.  This needed a high
level of familiarity with both the underlying software and Debian's
packaging practices.  Even so I caused a handful of regressions.

One thing that I found really good about dh is that you only have to
write code about things that are unusual.  This provides an excellent
opportunity to leave a comment next to each weird thing explaining why
it's there.
  https://browse.dgit.debian.org/xen.git/tree/debian/rules#n111

Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: d-shlibs (Was: Do we want to Require or Recommend DH)

Adrian Bunk-3
In reply to this post by Andreas Tille-5
On Tue, May 14, 2019 at 12:50:54PM +0200, Andreas Tille wrote:

> On Tue, May 14, 2019 at 01:12:17PM +0300, Adrian Bunk wrote:
> > On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> > > On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > > > > >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
> >
> > It is fine in the current "maintainer can do anything" world.
>
> Hmmm, I don't get it:  I'm using dh and in addition I'm using a tool
> that enforces library packaging policy.
>...

A tool nearly noone else uses or knows.

Spending time on trying to understand what such a tool does or why it is
needed in a specific package is not really different from spending time
trying to understand how a buildsystem works.

If it is generally useful it should be done by debhelper automatically,
otherwise it should not be used at all if the goal is to make it easier
for other people to make changes to your packages.

> Kind regards
>
>       Andreas.

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

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Holger Levsen-2
In reply to this post by Ian Jackson-2
On Tue, May 14, 2019 at 12:30:02PM +0100, Ian Jackson wrote:
> One thing that I found really good about dh is that you only have to
> write code about things that are unusual.  

indeed.

> This provides an excellent
> opportunity to leave a comment next to each weird thing explaining why
> it's there.
>   https://browse.dgit.debian.org/xen.git/tree/debian/rules#n111

wow, that's a *really* nicely documented rules file, kudos!


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: d-shlibs (Was: Do we want to Require or Recommend DH)

Jonas Smedegaard-2
In reply to this post by Adrian Bunk-3
Quoting Adrian Bunk (2019-05-14 13:47:02)

> On Tue, May 14, 2019 at 12:50:54PM +0200, Andreas Tille wrote:
> > On Tue, May 14, 2019 at 01:12:17PM +0300, Adrian Bunk wrote:
> > > On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> > > > On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > > > > > >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
> > >
> > > It is fine in the current "maintainer can do anything" world.
> >
> > Hmmm, I don't get it: I'm using dh and in addition I'm using a tool
> > that enforces library packaging policy.
> >...
>
> A tool nearly noone else uses or knows.
>
> Spending time on trying to understand what such a tool does or why it
> is needed in a specific package is not really different from spending
> time trying to understand how a buildsystem works.
>
> If it is generally useful it should be done by debhelper
> automatically, otherwise it should not be used at all if the goal is
> to make it easier for other people to make changes to your packages.
I like the smell of flexibility - e.g. debhelper offering a baseline on
top of which can be sprinkled more exotic tweaks as needed.

I dislike the smell of monoculture - e.g. banning or merging into
debhelper itself debhelper addon packages.


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Cdbs Features

Mo Zhou
In reply to this post by IOhannes m zmoelnig-2
Hi,

On 2019-05-14 07:59, IOhannes m zmölnig wrote:
> i've migrated many of my packages from cdbs to dh, but there's one
> feature which cdbs sports and which i miss strongly (at least: the last
> time i checked) in dh (so much, that i haven't converted a couple of
> packages): building of multiple "flavours".
> that is: building the same code-base multiple times, with differing
> configurations.

Could you please provide some examples about the case you mentioned?
I need exactly the "multiple flavours" feature for at least 2 packages:

https://salsa.debian.org/science-team/blis/blob/master/debian/rules
https://salsa.debian.org/science-team/openblas/blob/lumin/debian/rules

On amd64 the two source packages will be compiled 6 times in order to
produce 6 different variants.

I'm quite interested in taking a look at how cdbs deal with such case.

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Cdbs Features

IOhannes m zmoelnig-2
On 14.05.19 14:35, Mo Zhou wrote:
> I'm quite interested in taking a look at how cdbs deal with such case.


https://salsa.debian.org/multimedia-team/snd/blob/master/debian/rules
https://salsa.debian.org/multimedia-team/soundscaperenderer/blob/master/debian/rules

gfmdsrt
IOhannes

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Thibaut Paumard-8
In reply to this post by Andreas Tille-5
Le 14/05/2019 à 11:07, Andreas Tille a écrit :
> Can you give an example for a package that has a non-dh rules file
> "working for years" that gives as a result a package with no lintian
> warnings without changing this d/rules file?

Turns out I can't... I was thinking of some packages that I didn't have
to touch for years, but I checked and I actually converted them to dh
that many years ago...

Regards, Thibaut.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Ben Hutchings-3
In reply to this post by Andreas Tille-5
On Tue, 2019-05-14 at 12:54 +0200, Andreas Tille wrote:

> On Tue, May 14, 2019 at 10:38:06AM +0100, Ben Hutchings wrote:
> > On Tue, 2019-05-14 at 11:07 +0200, Andreas Tille wrote:
> > > Can you give an example for a package that has a non-dh rules file
> > > "working for years" that gives as a result a package with no lintian
> > > warnings without changing this d/rules file?
> >
> > linux is one.
> >
> > I did a lot of work to address lintian warnings last year, and most of
> > that did not involve debian/rules*.
>  
> Please call me over-picky but without checking the history is your
> "most" not a sign that there is at least one change to d/rules which was
> needed to fix some lintian issue.
I can only see one change that dh would have handled for us.

> I do not want you to change linux
> d/rules file and I think it is pretty safe from beeing NMUed just to
> switch to dh.

Indeed.  There is definitely scope for simplification, but it takes a
lot of knowledge and time to do that.

Given what others have said, I doubt that dh in its current state could
handle the multiple configurations, which is a shame.

> My point was that I doubt that any "working for years"
> d/rules has no lintian issues.

If "working for years" also implies unchanged for years, yes I agree.

Ben.

--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Cdbs Features [and 1 more messages]

Ian Jackson-2
In reply to this post by Mo Zhou
Mo Zhou writes ("Re: Cdbs Features"):
> On 2019-05-14 07:59, IOhannes m zmölnig wrote:
> > that is: building the same code-base multiple times, with differing
> > configurations.
>
> Could you please provide some examples about the case you mentioned?
> I need exactly the "multiple flavours" feature for at least 2 packages:
>
> https://salsa.debian.org/science-team/blis/blob/master/debian/rules
> https://salsa.debian.org/science-team/openblas/blob/lumin/debian/rules
...
> I'm quite interested in taking a look at how cdbs deal with such case.

IOhannes m zmölnig (Debian/GNU) writes ("Re: Cdbs Features"):
> On 14.05.19 14:35, Mo Zhou wrote:
> > I'm quite interested in taking a look at how cdbs deal with such case.
>
> https://salsa.debian.org/multimedia-team/snd/blob/master/debian/rules
> https://salsa.debian.org/multimedia-team/soundscaperenderer/blob/master/debian/rules

Wow.  This is like night and day.  My instinct is definitely that I
don't like cdbs but omg dh needs this feature.

I looked through the src:debhelper bugs and didn't see a request for
this.

Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Ian Jackson-2
In reply to this post by Holger Levsen-2
Holger Levsen writes ("Re: Do we want to Require or Recommend DH"):
> On Tue, May 14, 2019 at 12:30:02PM +0100, Ian Jackson wrote:
> > This provides an excellent
> > opportunity to leave a comment next to each weird thing explaining why
> > it's there.
> >   https://browse.dgit.debian.org/xen.git/tree/debian/rules#n111
>
> wow, that's a *really* nicely documented rules file, kudos!

Thanks for the compliment.  This is there for my benefit as much as
anyone else's.  Having done all the digging to figure all these things
out, I definitely want so save my future self from doing it all again!

Also documenting things means both that everyone else is much less
likely to delete it or break it, and that if it goes wrong or becomes
obsolete, we will be able to fix it or drop it as applicable.

But my point is if you have a handwritten rules file it ends up so
full of "obvious" boilerplate that it is difficult to see the trees
for the wood, and there isn't anywhere obvious to put this kind of
commentary.  I think both dh and cdbs make this easier.

Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Andreas Tille-5
On Tue, May 14, 2019 at 03:11:23PM +0100, Ian Jackson wrote:
>
> But my point is if you have a handwritten rules file it ends up so
> full of "obvious" boilerplate that it is difficult to see the trees
> for the wood, and there isn't anywhere obvious to put this kind of
> commentary.  I think both dh and cdbs make this easier.

That's another nice summary (and admittedly also true for cdbs).

Kind regards

     Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

QA expectations (Was: Do we want to Require or Recommend DH)

Helmut Grohne
In reply to this post by Andreas Tille-5
Let me briefly hijack the discussion for a side note. ;)

On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> 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.

After a failure, we tend to bash uploaders:
 * Why didn't they look at the debdiff?
 * Why didn't they run piuparts?
 * Why didn't they run lintian?
 * Why didn't they run autopkgtest?
 * Why didn't they do an arch-only/indep-only build?
 * Why didn't they test their package?
 * ...

The things you have to remember before doing an upload are insane.
Having humans remember all this crap is not a reasonable expectation. I
think our upload process is a bit like classical debhelper: You remember
to do all the things. We've seen the argument that the dh sequencer
sheds light on the unusual aspects of a package. I argue that this
should apply to QA as well. People shouldn't have to remember all the
QA. QA should just work and QA should tell people about the (unusual)
failures.

Now one can turn this argument upside down. One can say: unstable is the
QA area. Britney prevents testing migration on autopkgtest/piuparts/
missing binaries. In that case, we should simply stop filing such things
in the BTS and stop doing manual QA on unstable. It should be ok to
break unstable. But this is not going to work with transitions. Thus I
still think we're doing it wrong and unstable isn't the place to do the
QA we expect from everyone.

Now I wonder how to move forward with this (after the dh discussion).

Helmut

Reply | Threaded
Open this post in threaded view
|

Re: QA expectations (Was: Do we want to Require or Recommend DH)

Holger Levsen-2
On Tue, May 14, 2019 at 05:19:23PM +0200, Helmut Grohne wrote:
> The things you have to remember before doing an upload are insane.
> Having humans remember all this crap is not a reasonable expectation. I
> think our upload process is a bit like classical debhelper: You remember
> to do all the things. We've seen the argument that the dh sequencer
> sheds light on the unusual aspects of a package. I argue that this
> should apply to QA as well. People shouldn't have to remember all the
> QA. QA should just work and QA should tell people about the (unusual)
> failures.

agreed.

> Now one can turn this argument upside down. One can say: unstable is the
> QA area. Britney prevents testing migration on autopkgtest/piuparts/
> missing binaries. In that case, we should simply stop filing such things
> in the BTS and stop doing manual QA on unstable. It should be ok to
> break unstable. But this is not going to work with transitions. Thus I
> still think we're doing it wrong and unstable isn't the place to do the
> QA we expect from everyone.

have uploads go to unstable-proposed and then, after basic automatic QA
checks, go to unstable? (and then testing as usual today...)


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: QA expectations (Was: Do we want to Require or Recommend DH)

Johannes Schauer-3
Quoting Holger Levsen (2019-05-14 17:38:15)

> > Now one can turn this argument upside down. One can say: unstable is the QA
> > area. Britney prevents testing migration on autopkgtest/piuparts/ missing
> > binaries. In that case, we should simply stop filing such things in the BTS
> > and stop doing manual QA on unstable. It should be ok to break unstable.
> > But this is not going to work with transitions. Thus I still think we're
> > doing it wrong and unstable isn't the place to do the QA we expect from
> > everyone.
>
> have uploads go to unstable-proposed and then, after basic automatic QA
> checks, go to unstable? (and then testing as usual today...)
Doesn't a repository where all binary packages go before they are pushed into
unstable already exist?

deb http://incoming.debian.org/debian-buildd/ buildd-unstable main

So maybe instead of creating unstable-proposed, stuff should move from
buildd-unstable to unstable only after it successfully passed all kinds of
automatable QA tests?

Such an intermediate repository (be it unstable-proposed or buildd-unstable)
could highly improve the quality of unstable and make sure that whatever lands
in unstable will only have those bugs that are usually discovered by humans
only. It could also have other nice properties that currently only testing has,
like no Multi-Arch:same version skews because stuff could only move to unstable
after it has been built on all arches.

Thanks!

cheers, josch

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Cdbs Features

Tobias Frost-3
In reply to this post by Mo Zhou
On Tue, May 14, 2019 at 05:35:21AM -0700, Mo Zhou wrote:

> Hi,
>
> On 2019-05-14 07:59, IOhannes m zmölnig wrote:
> > i've migrated many of my packages from cdbs to dh, but there's one
> > feature which cdbs sports and which i miss strongly (at least: the last
> > time i checked) in dh (so much, that i haven't converted a couple of
> > packages): building of multiple "flavours".
> > that is: building the same code-base multiple times, with differing
> > configurations.
>
> Could you please provide some examples about the case you mentioned?
> I need exactly the "multiple flavours" feature for at least 2 packages:

"check" is compiling 2 flavours with dh:
https://tracker.debian.org/media/packages/c/check/rules-0.12.0-0.1
>

Reply | Threaded
Open this post in threaded view
|

Re: NMUs: Do we want to Require or Recommend DH

Sam Hartman-3
In reply to this post by Andreas Tille-5

I think there's a fairly clear consensus emerging that it's worth having
things to check when making a build system conversion.  Looking at
debdiff, ditherscope and reproducibility of the build all appear to be
important things to consider in such a case.

So, I think there is an emerging consensus against the idea of people
NMUing a package simply to convert it to dh.

First, I'd like to explicitly call for any last comments from people who would
like to see us permit NMUs simply to move packages toward dh.  Are there
any cases in which such an NMU should be permitted?

Finally, I'd like to focus discussion on an area where emerging
consensus is much less clear.

How do we feel about people making build system conversions when those
conversion make it easier to fix some other bug that they are fixing as
part of an NMU?
That is, imagine that a package is mishandling the combination of
systemd units and an init script.  As someone preparing an NMU, is it
reasonable to move to dh compat 12 from some other build system if I
believe doing so will make it easier for me to fix the bug and verify
the fix?

--Sam

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

gregor herrmann-3
In reply to this post by Adrian Bunk-3
On Tue, 14 May 2019 11:11:46 +0300, Adrian Bunk wrote:

> 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
> 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.
I hope I test them well enough :)
(And thanks for the kind feedback.)
 
> There is no perfect solution here and I also get your point,
> what should be taken into consideration is that there is a
> tradeoff between the benefits and the regressions of breaking
> changes like dh compat bumps or even conversions to dh.

Agreed; additional changes are additional chances for mistakes.

Still, I wanted to make the points that
- further adoption of dh(1) would make my life easier by creating
  fewer bugs of certain categories, and
- the possibility to switch a package to dh(1) (in cases where I know
  what that means, as in the example above with a typical perl
  module; not in complex cases like Marco's examples, and not just for
  the sake of it) would make bug fixing in NMUs easier for me and
  even prevent future bugs.
 

Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Rigmor Gustafsson: The Moon Is A Harsh Mistress

signature.asc (981 bytes) Download Attachment
123456