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

Scott Kitterman-5
On Monday, May 13, 2019 8:33:44 AM EDT Sam Hartman wrote:

> As promised, I'd like to start a discussion on whether we want to
> recommend using the dh command from debhelper as our preferred build
> system.
>
> As we can see on https://trends.debian.net/#build-systems a majority of
> packages already use dh.  So what would it mean to recommend dh?
>
> The New Maintainer's Guide [1] already is based around debhelper and dh
> and effectively recommends it strongly.  So it wouldn't mean that.
>
>   [1]: https://www.debian.org/doc/manuals/maint-guide/
>
> I guess at a simplest level, this would be validating the assumption
> that Lucas made behind trends.debian.net that not using dh is a "package
> smell," that maintainers should think about fixing.
>
> But I think what we're really talking about is whether maintainers
> should be expected to apply well-written patches to convert a package to
> using dh.  That is, is not using dh a bug.
>
> And at some level I think we're asking whether it is appropriate to NMU
> a package to convert it to dh.

Absolutely not.  A likely bug inducing drive-by NMU is not helpful.

>
> Today at least I don't think we're talking about making not using dh an
> RC bug.  It would not make a lot of sense to me to start there.
>
> Exceptions
> ==========
>
> Even if we do decide that not using dh is generally a bug, there are
> doubtless some exceptions.  If I remember correctly at least one of the
> language-specific packaging approaches is based around something else.
>
> There may be some classes of packages where dh doesn't make sense today.
>
> As part of this discussion I hope we will collect a list of exceptions
> where dh is not the right answer today.
>
> Why Would we Want This?
> =======================
>
> So, first, a lot of people have argued that dh makes packaging simpler.
> I've certainly found that to be true and use dh for any new package I
> make.
>
> That alone might be an argument for no dh being a package smell, but
> probably not a good argument for making not using dh a bug.  If dh makes
> your packaging simpler, that alone is probably sufficient motivation to
> adopt it where appropriate.
>
> There's another argument though.  Using dh might make things easier for
> others making changes to your packages.  It makes it easier for us to
> apply changes in things like how init scripts are called across the
> archive.
>
> 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.
>
> Evolution Towards a Team
> ========================
>
> I'd like to call out one specific thing from Andreas's quote and the
> general argument.  It's the belief that we've reached a point where in
> some cases uniformity is more important than maintainer preference.
>
> If true, that would be a big change for our community.  We've spent many
> years making it easy for maintainers to have a great deal of autonomy.
>
> I don't see that going away, but Andreas and others seem to be arguing
> that once we've found a good solution we should encourage uniform
> adoption to make it easier when we have to work on others' packages.
>
> Why Not Make this Change
> ========================
>
> The biggest argument I've heard against changes in this area is that
> moving towards dh and debhelper will introduce bugs.
> Like any significant change it requires effort both for development and
> for testing.
>
> One maintainer claimed that even if someone else wrote the patch it
> wasn't worth their effort to validate for a package where the existing
> build system was already working.
>
> Your Thoughts
> =============
>
> so, what do you think?
>
> I'll start with a general discussion but unless the answers are obvious
> follow up with some specific questions in a few days.
>
> Thanks for helping us explore this issue,
>
> --Sam

I think for new packages (with the exception of new packages maintained in a
team that has a different pattern), it's not unreasonable.  When starting from
scratch, dh is almost certainly no harder and usually easier than traditional
debhelper or other approaches.

For existing packages, not so much.  There are probably packages left that
would be trivial to convert, but I expect that most of those have been taken
care of already.  For complex packages, this can be really hard to get right.  
In the experiences I've had, converting packages that I maintain and have a
great deal of familiarity with is still fraught with error.

For really complex packages, they are going to be hard for someone not
familiar with the package to modify regardless of dh/debhelper.  My guess is
that if we try and push this direction the effort will mostly be spent where
there is the least potential for gain and the most risk of regressions.

For improvement of existing packages, I think there are better things to
expend resources on.

Scott K


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


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: Rolling Stones

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

Bootstrapping debhelper (was: Re: Do we want to Require or Recommend DH)

Johannes Schauer-3
In reply to this post by Sam Hartman-3
Quoting Sam Hartman (2019-05-13 21:49:20)

> >>>>> "Holger" == Holger Levsen <[hidden email]> writes:
>     Holger> On Mon, May 13, 2019 at 03:37:55PM -0400, Sam Hartman wrote:
>     Bernd> gcc also needs a compiler to build - so I think it should be
>     Bernd> safe to allow debhelper to build its package using
>     Bernd> debhelper. Or am I missing something here?
>     >> If we reach consensus on the overall idea, I was planning to ask
>     >> the debhelper maintainers whether they thought they needed an
>     >> exception for build-depends of debhelper.  Unless you think you
>     >> have special knowledge there, let's assume we can handle that
>     >> question as part of working through details.
>
>     Holger> I think being bootstrappable(.org) is a very worthwhile
>     Holger> feature, so please let's not make this harder than it
>     Holger> already is.
>
> Debhelper is arch all and because of its implementation its "opaque"
> binaries aren't very opaque as these things go.
> I think that the debhelper maintainers are aware of the issues of
> bootstrappability and can make an informed decision here.
Funnily, we just talked about Architecture:all packages in the bootstrapping
context in #debian-bootstrap today with debhelper maintainers. Take away
message: A binary package being Architecture:all doesn't remove it from the
bootstrap problem because that package also has to be installable i.e: all its
transitive Depends must exist as well and those may be Architecture:any, as is
also the case for debhelper. So applying this "exception" to the build-depends
on debhelper would not be enough. It would also have to be extended to the
transitive build dependencies of binaries in the installation sets of those.
Unfortunately, if you would indeed traverse the dependency graph in that way
you will quickly end up with a strongly connected component of several thousand
source packages in it:

https://bootstrap.debian.net/history.html

Fortunately, this is not really a problem (see below).

> I'll be shocked if there's not already a cycle involving building dpkg
> requiring a build of debhelper as an example.

I can even show you cycles involving dpkg and Haskell, OCaml, Python, Xorg and
ruby:

https://bootstrap.debian.net/essential.html

But all of this is hardly a problem in practice because much of the problem can
be worked around by cross-building many of the involved packages before
building packages natively. Of course (due to dependency cycles) not all source
packages can be cross compiled even if it would technically be possible to do
so, given the full archive. So all of this depends on the initial
cross-bootstrap phase. Great progress is being made by the rebootstrap project:

https://wiki.debian.org/HelmutGrohne/rebootstrap

And since recently we also have actual cross-builds of source packages that
satisfy their cross-build dependencies:

http://crossqa.debian.net/

Long story short: "exception for build-depends on debhelper" as outlined above
is not the right way forward to make debhelper bootstrappable. The correct
solution is a bit more involved and (due to the prevalence of debhelper)
probably involves making debhelper (and its installation set) be part of the
cross-bootstrap. But debhelper maintainers are already lurking in
#debian-bootstrap so I guess this topic is already covered. :)

Thanks!

cheers, josch

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

Re: Do we want to Require or Recommend DH

Thomas Goirand-3
In reply to this post by Sam Hartman-3
On 5/13/19 6:28 PM, Sam Hartman wrote:

>>>>>> "Thomas" == Thomas Goirand <[hidden email]> writes:
>
>     Thomas> Now, I have another example, which is quite the opposite one
>     Thomas> of what you gave as example:
>
>     Thomas> https://salsa.debian.org/openstack-team/debian/openstack-debian-images/blob/debian/stein/debian/rules
>
>     Thomas> Why would one want to switch that one to something else? The
>     Thomas> package, basically, consists of a shell script and a man
>     Thomas> page only. The minimalism of this package doesn't require an
>     Thomas> over-engineered dh sequencer, does it? I'm happy the way the
>     Thomas> package is, and I don't think I'd switch to the dh sequencer
>     Thomas> *UNLESS* someone has a better argument than "it's new", or
>     Thomas> "debian/rules will be smaller", or even "it's going to
>     Thomas> evolve without you even noticing it" (which is more scary
>     Thomas> than anything else, which is IMO one of the defects of the
>     Thomas> dh sequencer).
>
> Could you make an attempt at articulating this as an exception?

I agree this package is probably an exception.

On 5/13/19 7:42 PM, Holger Levsen wrote:
> - because it makes archive wide changes a lot easier.

Right.

Though I very much doubt this super-simple package will miss any
archive-wide change applied through modifying the way dh sequences
things. If this happens, it will mean we're over-engineering things.

> - it's also simpler to understand.

There, I don't agree. To fully understand how the dh sequencer works,
one must first understand the 6 mandatory debian/rules targets, and how
they are called. dh will hide everything. It isn't simpler, it *LOOKS*
simpler, but it's a way more complex.

When dh appeared, it took me months to accept it, because I didn't like
it was hiding everything. I appreciate why it's done, and I do use dh in
most of my packages, but it's still the case that I would prefer if it
wasn't hiding everything.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Iustin Pop-3
In reply to this post by Thomas Goirand-3
On 2019-05-13 17:58:47, Thomas Goirand wrote:

> On 5/13/19 3:57 PM, Marco d'Itri wrote:
> > On May 13, Sam Hartman <[hidden email]> wrote:
> >
> >> As promised, I'd like to start a discussion on whether we want to
> >> recommend using the dh command from debhelper as our preferred build
> >> system.
> > I have already asked this last time, but nobody answered.
> > I use debhelper in all of my packages but I have never switched to dh:
> > why should I bother?
> > "Everybody is doing this" is not much of an argument.
> >
> > Would dh really make a debian/rules file like these simpler to
> > understand? Can somebody try to win me over with a patch? :-)
> >
> > https://salsa.debian.org/md/inn2/blob/master/debian/rules
>
> Without looking much, without checking if the package even builds,
> here's a possible result:
>
> https://salsa.debian.org/zigo/inn2/blob/master/debian/rules
>
> Admittedly, I haven't understood all of the hacks you did (what's the
> $(no_package) thing for?).
>
> It's only 15 lines shorter, but that's not the point. The point is that
> it only declares things you are not doing like everyone else.
>
> Now, I have another example, which is quite the opposite one of what you
> gave as example:
>
> https://salsa.debian.org/openstack-team/debian/openstack-debian-images/blob/debian/stein/debian/rules
>
> Why would one want to switch that one to something else? The package,
> basically, consists of a shell script and a man page only. The
> minimalism of this package doesn't require an over-engineered dh
> sequencer, does it? I'm happy the way the package is, and I don't think
> I'd switch to the dh sequencer *UNLESS* someone has a better argument
> than "it's new", or "debian/rules will be smaller", or even "it's going
> to evolve without you even noticing it" (which is more scary than
> anything else, which is IMO one of the defects of the dh sequencer).
This example is indeed interesting, but IMO for the opposite reason. The
last commit on this file was to fix #853907 which is about the
intricacies of exactly which targets to call in which sequence for the
package type. Which dh avoids, because it has logic to do things rather
than require the human to write the exact code needed - since we don't
have (or didn't have at that time) good enough pre-upload tests.

So in this case, wouldn't dh have completely avoided the bug?

Very side note: why is that package a binary package instead of
arch-indep, if it contains only a man page?

regards,
iustin

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

Re: Cdbs Features

Sean Whitton
In reply to this post by Sam Hartman-3
Hello Sam,

On Mon 13 May 2019 at 12:22PM -04, Sam Hartman wrote:

>>>>>> "Holger" == Holger Levsen <[hidden email]> writes:
>     Holger> - packages using cdbs. cdbs has features dh doesnt have and
>     Holger> I dont think it's wrong to use cdbs. (
>
> Just for my information, what are the big features cdbs has that dh does
> not?

I don't know cdbs well, so I don't know what big features it might have
that dh does not have, but I do know that the Haskell package ecosystem
relies on cdbs addon code.  I.e. in our d/rules we have

    include /usr/share/cdbs/1/rules/debhelper.mk
    include /usr/share/cdbs/1/class/hlibrary.mk

There have been attempts to rewrite what hlibrary.mk does as a
'dh_haskell' tool.  These attempts stalled.

Switching the entire Haskell ecosystem over to use dh would be a massive
amount of work, as the new dh_haskell would need a lot of testing etc.
So Haskell libraries and apps would probably have to be one of the
exceptions.

--
Sean Whitton

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

Re: Do we want to Require or Recommend DH

Sean Whitton
In reply to this post by Scott Kitterman-5
Hello,

On Mon 13 May 2019 at 04:32PM -04, Scott Kitterman wrote:

> I think for new packages (with the exception of new packages maintained in a
> team that has a different pattern), it's not unreasonable.  When starting from
> scratch, dh is almost certainly no harder and usually easier than traditional
> debhelper or other approaches.
>
> For existing packages, not so much.  There are probably packages left that
> would be trivial to convert, but I expect that most of those have been taken
> care of already.  For complex packages, this can be really hard to get right.
> In the experiences I've had, converting packages that I maintain and have a
> great deal of familiarity with is still fraught with error.
>
> For really complex packages, they are going to be hard for someone not
> familiar with the package to modify regardless of dh/debhelper.  My guess is
> that if we try and push this direction the effort will mostly be spent where
> there is the least potential for gain and the most risk of regressions.
>
> For improvement of existing packages, I think there are better things to
> expend resources on.
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.

--
Sean Whitton

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

Re: Do we want to Require or Recommend DH

Helmut Grohne
In reply to this post by Sam Hartman-5
Hi,

On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
> I'd like to call out one specific thing from Andreas's quote and the
> general argument.  It's the belief that we've reached a point where in
> some cases uniformity is more important than maintainer preference.

I second this.

With my cross/bootstrap maintainer hat (it's not an official hat, but I
think I have this hat at this point in time), I can say that this
uniformity is key to making archive-wide change feasible. During my work
on cross/bootstrap, I've sent more than 1500 patches. I guess that
almost half of those were one of:

 * use dh_auto_configure
 * use dh_auto_build
 * don't strip before dh_strip
 * bump debhelper compat level

In other words, a significant chunk of packages would have just worked
had they used debhelper. On top of that, I observed that a fair number
of broken packages had one other bug "please make the build
reproducible". I would be surprised if the reproducible experience is
much different from mine. Maintainer preference has a real cost to the
project and that cost needs to be measured in weeks or months, not
minutes.

Due to the added friction I've generally avoided fixing packages that
were using cdbs or no debhelper at all. My personal view is that we
should stop using cdbs entirely, but I'm not sure that consensus is
achievable on this point.

This is a statement towards the general direction. I have no good idea
how to turn that into policy or the like.

Given my little experience with Haskell packages, I would exempt the
haskell ecosystem from a rule.

Hope this helps as a data point

Helmut

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Paul Wise via nm
In reply to this post by Sam Hartman-5
On Mon, May 13, 2019 at 8:34 PM Sam Hartman wrote:

> As promised, I'd like to start a discussion on whether we want to
> recommend using the dh command from debhelper as our preferred build
> system.

This is already the case AFAICT.

> But I think what we're really talking about is whether maintainers
> should be expected to apply well-written patches to convert a package to
> using dh.  That is, is not using dh a bug.
>
> And at some level I think we're asking whether it is appropriate to NMU
> a package to convert it to dh.
>
> Today at least I don't think we're talking about making not using dh an
> RC bug.  It would not make a lot of sense to me to start there.

I don't think these are appropriate.

I think conversion to dh should only be done when doing hostile
hijacking of packages, salvaging packages, adopting packages,
orphaning packages or team/maintainer uploads and only if the person
doing the conversion builds the package twice (with and without dh),
inspects the resulting changes to the binary packages with diffoscope
and is confident that each change is appropriate.

> Exceptions
> ==========

I think we should allow the cdbs maintainer to use cdbs instead of dh
in their packages :)

> so, what do you think?

I don't think there is any way to require packages use dh, unless you
want to forcibly remove/orphan packages or remove maintainers that
won't use dh?

I think that we should encourage experimentation with better
alternatives to dh, such as if someone wanted to revive the efforts to
build Debian packages using Gentoo's ebuild framework.

http://penta.debconf.org/dc7_schedule/events/69.en.html

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Thomas Goirand-3
In reply to this post by Iustin Pop-3
On 5/13/19 11:42 PM, Iustin Pop wrote:
> Very side note: why is that package a binary package instead of
> arch-indep, if it contains only a man page?

Not only a man page, but a shell script that either creates a Qcow2
image for OpenStack or installs Debian on bare-metal.

With the way it works, it only makes sense on the listed architecture
where it has been tested. I wish there was a possibility to say "it's
arch all, but only works on these", but in Debian, we can't.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Cdbs Features

IOhannes m zmoelnig-2
In reply to this post by Sam Hartman-3


On 13.05.19 18:22, Sam Hartman wrote:
>>>>>> "Holger" == Holger Levsen <[hidden email]> writes:
>     Holger> - packages using cdbs. cdbs has features dh doesnt have and
>     Holger> I dont think it's wrong to use cdbs. (
>
> Just for my information, what are the big features cdbs has that dh does
> not?
>

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.

while it is possible to do that with dh, it amounts to either a lot of
near-duplicate lines or quite some GNU make trickery, which i'd rather
not spread across multiple d/rules


fgamsdr
IOhannes

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Adrian Bunk-3
In reply to this post by gregor herrmann-3
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 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.

In my experience people are already pushing too much towards
"use dh with latest compat" in existing packages, and it would be
better to slow that down rather than accelerate it even further.

> Cheers,
> gregor

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

Johannes Schauer-3
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

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

Re: Do we want to Require or Recommend DH

Andrey Rahmatullin-3
In reply to this post by Adrian Bunk-3
On Tue, May 14, 2019 at 11:11:46AM +0300, Adrian Bunk wrote:

> 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.
One can go further and say that people uploading broken packages are the
actual problem. After all, we have several classes of bugs caused by
people uploading .debs built in a broken env.
Not sure if we can fix this and how.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
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 Thibaut Paumard-8
On Mon, May 13, 2019 at 04:22:49PM +0200, Thibaut Paumard wrote:
> > Why Not Make this Change
> > ========================
>
> I would use dh for any new package and converting trivial packages is...
> trivial. However converting a package with a more convoluted rules files
> will take humanpower. While it may be justified to convert a mildly
> complex rules file on a package that has some activity, I don't think I
> would invest those resources to convert a package that's been working
> for years without anyone touching it's rules files.

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?

Kind regards

       Andreas.

--
http://fam-tille.de

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 Andrey Rahmatullin-3
On Tue, May 14, 2019 at 02:07:11PM +0500, Andrey Rahmatullin wrote:
> One can go further and say that people uploading broken packages are the
> actual problem. After all, we have several classes of bugs caused by
> people uploading .debs built in a broken env.
> Not sure if we can fix this and how.

forbid binary uploads for everyone. allow binary uploads for some people
for some packages sometimes.


--
tschau,
        Holger

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

Dance like no one's watching. Encrypt like everyone is.

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

Re: Do we want to Require or Recommend DH

Andrey Rahmatullin-3
On Tue, May 14, 2019 at 09:10:04AM +0000, Holger Levsen wrote:
> On Tue, May 14, 2019 at 02:07:11PM +0500, Andrey Rahmatullin wrote:
> > One can go further and say that people uploading broken packages are the
> > actual problem. After all, we have several classes of bugs caused by
> > people uploading .debs built in a broken env.
> > Not sure if we can fix this and how.
>
> forbid binary uploads for everyone. allow binary uploads for some people
> for some packages sometimes.
People will find a way. Adrian was talking about uploading broken source
packages, I just provided a different example of the same problem.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
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 Adrian Bunk-3
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 | 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 11:07 +0200, Andreas Tille wrote:

> On Mon, May 13, 2019 at 04:22:49PM +0200, Thibaut Paumard wrote:
> > > Why Not Make this Change
> > > ========================
> >
> > I would use dh for any new package and converting trivial packages is...
> > trivial. However converting a package with a more convoluted rules files
> > will take humanpower. While it may be justified to convert a mildly
> > complex rules file on a package that has some activity, I don't think I
> > would invest those resources to convert a package that's been working
> > for years without anyone touching it's rules files.
>
> 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*.

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: 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 11:30:11AM +0200, Andreas Tille wrote:

> 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

It is fine in the current "maintainer can do anything" world.

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

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

This is pretty much impossible.

dh is nice when it supports whatever you want to do,
but for everything else it is just another layer you
have to understand when debugging and fixing problems.

Imagine you want to make ghc pass an additional flag to gcc.

The layering is as follows:
Debian haskell scripts
upstream build system
ghc
gcc

You end up at questions:
How can I tell ghc to pass a parameter to gcc?
How can I tell the upstream build system to pass a parameter to ghc?
How can I tell the Debian haskell scripts to pass a parameter to the
upstream build system?


debian/rules is already a 3-line
#!/usr/bin/make -f

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/hlibrary.mk


It wouldn't help you if that would be changed to a 3-line
#!/usr/bin/make -f

%:
        dh $@ --with haskell


In either case there is a huge Haskell-specific build machinery you
have to understand for making some kinds of debugging or changes.


> 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

123456