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: NMUs: Do we want to Require or Recommend DH

Andreas Tille-2
Hi Sam,

On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote:
> 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.

I admit despite I'm in big favour of having the majority of packages
converted to dh I would not feel my time well spent to browse the
archive for packages that might be "smelling" like candidates.

> Are there
> any cases in which such an NMU should be permitted?

If a package has a RC bug or some important bug that annoys me for a
certain reason and fixing it would be easier by just doing a dh
conversion is a pretty good candidate for me.  Or if I need to touch
such a package and the conversion is obviously very simple I would like
to do so.  I will do so in case I'm a member of the team that maintains
the package without question - otherwise I'd give the maintainer a
warning and ask for permission (but will usually write something like
"If I do not hear from you in X days I assume you agree with this.")
 
> 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's one of the cases I mentioned above.

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

Good example for a valid dh conversion.

Kind regards

      Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

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

Adrian Bunk-3
In reply to this post by Helmut Grohne
On Tue, May 14, 2019 at 05:19:23PM +0200, Helmut Grohne wrote:

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

Not running lintian before uploading to unstable shouldn't happen.

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

"Check that your changes are working" is pretty basic and sane.

If the only change was fixing a missing dependency, check that the built
binary package actually has the correct dependency added.

If you rewrote the whole build system, check that the built packages
still have the same contents and still work.

If you are trying to fix a build failure on an architecture,
make a testbuild on a porterbox instead of 10 uploads to unstable.

>...
> People shouldn't have to remember all the QA. QA should just work and
> QA should tell people about the (unusual) failures.
>...

QA is good for finding some kinds of common problems.

But it is not a replacement for people being careful when making changes.

> Helmut

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: NMUs: Do we want to Require or Recommend DH

Adrian Bunk-3
In reply to this post by Sam Hartman-3
On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote:
>...
> 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?

What happens if the maintainer dislikes the change?

The maintainer clearly has the right to revert such an NMU,
and the opinion about the NMU expressed in the changelog or
elsewhere might not be friendly.

There might be cases where it is appropriate, but I wouldn't issue
a general recommendation to do build system conversions in NMUs.

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

Doing a build system conversion properly requires first understanding
what the old build system did, and later verifying that the changes
didn't break anything.

It might bring long-term benefits, but if anyone claims that for an NMU
this is easier than a minimal fix I strongly suspect it is only easy due
to lack of diligence.

> --Sam

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

Bernd Zeimetz
In reply to this post by Thomas Goirand-3


On 5/13/19 11:31 PM, Thomas Goirand wrote:
>> - 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.

You have to understand that in any case. Doesn't matter if its dh, cdbs
or old dh_* stuff.

> dh will hide everything. It isn't simpler, it *LOOKS*
> simpler, but it's a way more complex.

No idea where you think that dh hides something - make and dh both print
what they are doing.



--
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Moritz Mühlenhoff-2
In reply to this post by Simon McVittie-7
Simon McVittie <[hidden email]> schrieb:
> Packages using dh also make it a lot more straightforward to do
> archive-wide changes - similar to the benefit of using debhelper, but
> for changes that affect the "shape" of the build system rather than the
> details of individual steps. As a concrete example,

Or e.g. the changes which were necessary to inject the hardening
build flags; I submitted a few hundred to the BTS when we got started
with it, which was very simple for anything using dh (where is was
enabled by default when using compat level 9) and needed more effort
for anything based on traditional debhelper and or even not using
debhelper at all.

Cheers,
        Moritz

Reply | Threaded
Open this post in threaded view
|

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

Paul Wise via nm
In reply to this post by Sam Hartman-3
On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote:

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

If the maintainer is MIA enough to not express an opinion when asked
if adding a dh conversion to the NMU is fine, probably the package
should be orphaned/salvaged instead of NMUed, which would bring the dh
conversion into scope.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

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

Scott Kitterman-5


On May 15, 2019 1:13:52 AM UTC, Paul Wise <[hidden email]> wrote:

>On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote:
>
>> 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?
>
>If the maintainer is MIA enough to not express an opinion when asked
>if adding a dh conversion to the NMU is fine, probably the package
>should be orphaned/salvaged instead of NMUed, which would bring the dh
>conversion into scope.

I'd think the timeline for that would be longer than the week or two it takes to do an NMU.

Scott K

Reply | Threaded
Open this post in threaded view
|

Re: Cdbs Features

Marc Dequènes (Duck)
In reply to this post by Sean Whitton
Quack,

On 2019-05-14 11:24, Sean Whitton wrote:

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

It took months to get somethings working for Python and Ruby and in the
end years to polish all the things and migrate all packages, so it's
clearly going to take quite some time.

I think one of the major feature of CDBS is the way stages are grouped
in make rules and you can hook onto it or even override. Coupled with
patsubst it makes some kind of loops you can use to iterate over groups
of packages, which is very handy when you need to build for various
versions of an interpreter. So unlike DH you can really add or override
parts of these loops if your package requires it. But in the end all
these rules are complex to read and maintain, and if they were very
useful in the past they also pushed debhelper/dh into going forward with
more bold features and I don't think CDBS adds much to the table
nowadays.

I would also point out that the maintenance of CDBS has been on Jonas
Smedegaard's shoulders for years now and it has been difficult having
almost no backup (which I'm partly responsible of). I think I was mostly
able to convince him we should work on a retirement plan but I've had no
time to do anything about it. Bugs like #885407 and others are still
around while we are close to release, thus I still think this is the
best course of action.


On the more general topic, I believe there should be room for new tools
to emerge and not-being-dh should never be a RC or even important bug.
Nevertheless I think this tool has grown well and a strong
recommendation would be fine. I believe as a project we could agree on
major goals around deprecating tools that lost traction and proper
maintenance, old versions of the tools, old patch formats and so on, and
encouraging contribution around it. We could also agree on some practice
to avoid like direct source patching (especially when not on a VCS). But
this way you're still free to use the patching system that suits you or
build your own and suggest it to the community; that's how many of our
tools were built.

As for using NMU I think this is a bad idea. Even if we're supposed to
care after a NMU, this is no long-term maintenance and a returning busy
maintainer would not really appreciate this. I believe adoption,
becoming co-maintainer or creating a team would be better if you want to
make drastic changes on a package and your one-off patch lingers in the
BTS.

\_o<

--
Marc Dequènes

Reply | Threaded
Open this post in threaded view
|

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

Jonas Smedegaard-2
In reply to this post by Scott Kitterman-5
Quoting Scott Kitterman (2019-05-15 04:47:48)

>
>
> On May 15, 2019 1:13:52 AM UTC, Paul Wise <[hidden email]> wrote:
> >On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote:
> >
> >> 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?
> >
> >If the maintainer is MIA enough to not express an opinion when asked
> >if adding a dh conversion to the NMU is fine, probably the package
> >should be orphaned/salvaged instead of NMUed, which would bring the
> >dh conversion into scope.
>
> I'd think the timeline for that would be longer than the week or two
> it takes to do an NMU.
Yes the timeline of an NMU being short is the very issue as I see it:
Switching build system may be easy to do but less easy to maintain for
the maintainer - regardless of popularity in general.

No, major package refactoring like change of build system is
unacceptable in NMUs, because it strongly affects long-term maintenance.

Real underlying question seems instead to be this:

Do we tolerate maintainers using a "wrong" packaging style - i.e. an
unpopular style fewer find easy to do NMUs for?

Yes, let's recommend what is popular.  But not this.


 - 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: Do we want to Require or Recommend DH

Simon McVittie-7
In reply to this post by Thomas Goirand-3
On Mon, 13 May 2019 at 17:58:47 +0200, Thomas Goirand wrote:
> 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.

I would personally *especially* use dh for packages this simple.

It uses dh_testroot, so it probably can't have Rules-Requires-Root: no,
and needs to be built as (fake)root indefinitely - even though a package
this simple can almost certainly be built correctly without fakeroot.

At some point in the past someone, probably you, has had to think about:

- which dh_foo helpers need to be included in the list and which can be
  excluded
- which order they go in

which has probably been done correctly, but maybe not - I can't tell. The
fact that they might have been done incorrectly isn't so bad: if they're
wrong it's just a bug, and we can fix bugs. The fact that it would take
thought to work out whether they're correct is more problematic.

At some point in the past someone, probably you, has had to make
this package Policy-compliant when the -arch and -indep targets became
mandatory in order to make Build-Depends-Indep practically useful (perhaps
this package is new enough that you did that as part of its initial
packaging, but either way, someone had to think about it). Adding the
-arch and -indep targets went as slowly as it did because many packages
needed (trivial) per-package changes to enact it.

Part of the value of a dh rules file is that (as Ian Jackson said
elsewhere in this thread) the boilerplate part is trivial, and each
non-boilerplate part (override target) indicates something that is unusual
about this package. A minimal dh rules file immediately tells a reader
"this is a completely ordinary build process" and that's a valuable
thing to convey to a reader.

    smcv

Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-7
In reply to this post by Johannes Schauer-3
On Tue, 14 May 2019 at 18:19:47 +0200, Johannes Schauer wrote:
> 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?

Prior art: Ubuntu already does this, gating the transition with a version
of Debian's testing migration scripts that has been configured for a 0 day
delay for all urgencies.

The down side of this is that families of packages occasionally get stuck
in their incoming-equivalent because of versioned dependencies, and a
transition is needed to get them into their testing-equivalent. Perhaps
some Ubuntu developers could comment on the extent to which this is a
practical problem?

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

Ubuntu is more able to do this than Debian, because Ubuntu's slowest,
least reliable and least-well-supported architectures are faster, more
reliable and better-supported than Debian's. I'm not sure that we really
want to be waiting for important fixes (especially in large packages
like compilers, web browsers and the kernel) to build successfully on
mips(el), or requiring that their build-time tests have few enough race
conditions to be successful even on slower architectures, before they
can reach the part of the archive that developers use in practice?

    smcv

Reply | Threaded
Open this post in threaded view
|

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

Enrico Zini
In reply to this post by Sam Hartman-3
On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote:

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

I see various scenarios:

 - if a package is generally actively maintained, except the maintainer
   is currently unresponsive for some reason and there is a RC bug to
   fix, I could understand frowning upon a build system conversion in an
   NMU.

 - if a package has bugs that can all be fixed trivially with a build
   system conversion, I would see no reason not to do such a conversion,
   even in an NMU.

 - a change of build system in a complex package would be more
   controversial than in a trivial package.

 - if a package has had an inactive and unresponsive maintainer for a
   long time, it would indeed be a case for salvaging.

   I could however imagine someone having enough energy to dust off old
   packages in the archive, while not having enough energy to pick up
   maintenance of lots of old dusty packages.

   I would consider the idea of salvaging+orphaning, like following the
   salvaging procedure but setting the maintainer to qa instead.

 - I'd say that orphaned packages can be uncontroversially be converted
   to dh.


With a consensus of having dh as the default build system, and the
understanding that some packages have good reasons not to use dh, I'd
like a way to tell when a package is not using dh for a reason, from
when a package is not using dh because the maintainer has not gotten
around to it yet.

I'd propose to recommend dh as the default build system, and document in
README.source if there are reasons to use something else.

At that point, one could look at README.source to see if changing build
system would be an possible strategy for fixing bugs in an NMU.


Enrico

--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <[hidden email]>

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

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

Jonas Smedegaard-2
Quoting Enrico Zini (2019-05-15 11:31:46)

> On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote:
>
> > 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?
>
> I see various scenarios:
>
>  - if a package is generally actively maintained, except the
>    maintainer is currently unresponsive for some reason and there is a
>    RC bug to fix, I could understand frowning upon a build system
>    conversion in an NMU.
>
>  - if a package has bugs that can all be fixed trivially with a build
>    system conversion, I would see no reason not to do such a
>    conversion, even in an NMU.
>
>  - a change of build system in a complex package would be more
>    controversial than in a trivial package.
>
>  - if a package has had an inactive and unresponsive maintainer for a
>    long time, it would indeed be a case for salvaging.
>
>    I could however imagine someone having enough energy to dust off
>    old packages in the archive, while not having enough energy to pick
>    up maintenance of lots of old dusty packages.
>
>    I would consider the idea of salvaging+orphaning, like following
>    the salvaging procedure but setting the maintainer to qa instead.
>
>  - I'd say that orphaned packages can be uncontroversially be
>    converted to dh.
Very well said.  I agree ith all of it.


> With a consensus of having dh as the default build system, and the
> understanding that some packages have good reasons not to use dh, I'd
> like a way to tell when a package is not using dh for a reason, from
> when a package is not using dh because the maintainer has not gotten
> around to it yet.
>
> I'd propose to recommend dh as the default build system, and document
> in README.source if there are reasons to use something else.
>
> At that point, one could look at README.source to see if changing
> build system would be an possible strategy for fixing bugs in an NMU.
Great suggestion!


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

dh_testroot usage is still always required (was Re: Do we want to Require or Recommend DH)

Guillem Jover
In reply to this post by Simon McVittie-7
On Wed, 2019-05-15 at 09:18:26 +0100, Simon McVittie wrote:
> It uses dh_testroot, so it probably can't have Rules-Requires-Root: no,
> and needs to be built as (fake)root indefinitely - even though a package
> this simple can almost certainly be built correctly without fakeroot.

You've mention this twice in the thread, and this is incorrect. Actually,
removing dh_testroot would be just harmful. Whether a package is to be
built with R³ or not depends in most part on the builder environment,
not the packaging. If you use a new enough dpkg-buildpackage, then it
will enable it if the packaging allows it, otherwise it should require
(fake)root; or if calling debian/rules by hand, even when the packaging
has specified it can be built with no R³.

(See dpkg itself for an example of this.)

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

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

Benjamin Drung-6
In reply to this post by Enrico Zini
Am Mittwoch, den 15.05.2019, 11:31 +0200 schrieb Enrico Zini:
> I'd propose to recommend dh as the default build system, and document
> in README.source if there are reasons to use something else.
>
> At that point, one could look at README.source to see if changing
> build system would be an possible strategy for fixing bugs in an NMU.

Or introduce a lintian check for not using dh. Then the maintainer
could override lintian and document the reason for it in the override.

--
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: [hidden email] | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
In reply to this post by Enrico Zini
Enrico Zini writes ("Re: NMUs: Do we want to Require or Recommend DH"):
> I'd propose to recommend dh as the default build system, and document in
> README.source if there are reasons to use something else.
>
> At that point, one could look at README.source to see if changing build
> system would be an possible strategy for fixing bugs in an NMU.

This is a great idea.  Obviously such a policy/process change would
have to come with a significant lead time so that everyone would have
a chance to do an upload with an appropriate README.source.

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: NMUs: Do we want to Require or Recommend DH

Andreas Tille-5
In reply to this post by Benjamin Drung-6
Hi,

On Wed, May 15, 2019 at 02:09:14PM +0200, Benjamin Drung wrote:
> Am Mittwoch, den 15.05.2019, 11:31 +0200 schrieb Enrico Zini:
> > I'd propose to recommend dh as the default build system, and document
> > in README.source if there are reasons to use something else.
> >
> > At that point, one could look at README.source to see if changing
> > build system would be an possible strategy for fixing bugs in an NMU.

The README.source idea is good ...
 
> Or introduce a lintian check for not using dh. Then the maintainer
> could override lintian and document the reason for it in the override.

... but I think the documented lintian override is better since
it is more connected to code than free text.

Kind regards

        Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Jonathan Dowland
In reply to this post by Paul Wise via nm
On Tue, May 14, 2019 at 02:27:30PM +0800, Paul Wise wrote:
>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.

Here you state your opinion but you haven't provided any rationale for
it.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Jonathan Dowland
In reply to this post by Thomas Goirand-3
On Mon, May 13, 2019 at 05:58:47PM +0200, Thomas Goirand wrote:
>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 maintain one of the simplest possible packages (in non-free),
doom-wad-shareware, that is even simpler: it consists of three files total:

    /usr/share/doc/doom-wad-shareware/changelog.Debian.gz
    /usr/share/doc/doom-wad-shareware/copyright
    /usr/share/games/doom/doom1.wad

For the source package, I thought "why do I need debhelper for such a simple
package". And so I did things by hand instead¹, and I still screwed something
up².

This is clearly a stupid case of premature optimisation, yak shaving, etc.; I
suspect many other instances of "why bother for such a simple package" in the
archive have elements of these too.

(An unrelated, but amusing mess-up in this trivial package: for the first 11
years, there was a version mismatch between what was actually in the .deb and
what the version claimed)

1. https://sources.debian.org/src/doom-wad-shareware/1.9.fixed-2/debian/rules/
2. https://tracker.debian.org/news/449441/accepted-doom-wad-shareware-19fixed-2-source-all/

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

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

Helmut Grohne
In reply to this post by Simon McVittie-7
On Wed, May 15, 2019 at 09:28:59AM +0100, Simon McVittie wrote:
> Prior art: Ubuntu already does this, gating the transition with a version
> of Debian's testing migration scripts that has been configured for a 0 day
> delay for all urgencies.

Yes. Colin Watson even had a talk about this in Vaumarcus.
http://penta.debconf.org/dc13_schedule/events/1028.en.html Copying the
strategy to Debian failed to gain traction thus far. I wonder whether we
could do this opt-in (or maybe as some external service that forwards
tested packages to the archive) anyhow. I have little clue about what
would be required to implement it in the archive.

> Ubuntu is more able to do this than Debian, because Ubuntu's slowest,
> least reliable and least-well-supported architectures are faster, more
> reliable and better-supported than Debian's. I'm not sure that we really
> want to be waiting for important fixes (especially in large packages
> like compilers, web browsers and the kernel) to build successfully on
> mips(el), or requiring that their build-time tests have few enough race
> conditions to be successful even on slower architectures, before they
> can reach the part of the archive that developers use in practice?

Given my experience with Multi-Arch: same skews in unstable, it does not
appear to me that packages get stuck for that long. If they do, that's
due to a FTBFS (which is exactly the thing we want to prevent from
entering unstable). buildd speed is a concern for other reasons, so if
an architecture fails to keep up for a longer time, it should likely be
demoted to ports.

Helmut

123456