Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
- To: Gregor Riepl <firstname.lastname@example.org>
- Cc: John Paul Adrian Glaubitz <email@example.com>, Matthias Klose <firstname.lastname@example.org>, YunQiang Su <email@example.com>, firstname.lastname@example.org, email@example.com, DSA list <firstname.lastname@example.org>, email@example.com, Debian GCC Maintainers <firstname.lastname@example.org>, email@example.com
- Subject: Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
- From: Adam Borowski <firstname.lastname@example.org>
- Date: Wed, 12 Dec 2018 04:03:25 +0100
- Message-id: <[🔎] email@example.com>
- In-reply-to: <[🔎] firstname.lastname@example.org>
- References: <email@example.com> <CAKcpw6UH4XNfc4tZfWX7gsN+8vEqq01mMYR3Um5mCwbsWKf5mA@mail.gmail.com> <[🔎] firstname.lastname@example.org> <[🔎] email@example.com> <[🔎] firstname.lastname@example.org>
[Oy vey, crosspost list from hell -- not sure how to trim...]
On Tue, Dec 11, 2018 at 09:46:21PM +0100, Gregor Riepl wrote:
> I do think this just reinforces the point that second-class architectures
> should have better, more robust support from the Debian project.
> For example, arch-specific packages most decidedly have a place in Debian
> The build and package delivery infrastructure should offer the same features
> for both first and second class archs, including installer image building for
> all "tiers" (stable, testing, unstable).
It seems to me that the important bit is the testing suite. As a (now
lapsed) x32 porter, I tried to implement that on my own (goal being an
unofficial, weakly security supported Jessie for x32). And tracking
testing on my own proved to be too hard. What directly defeated me were
binNMUs: with every arch having its own NMU counter and hidden triggers,
this is already a mess. Add NMUs due to private ported packages, and all
hell breaks loose.
The rest is easy in comparison: a porter team can decide whether to snapshot
testing as unofficial stable; point releases are a matter of running a
buildd job (and fixing failures), same for security. We'd be able to
concentrate on actual arch-specific issues.
> The main difference should (IMHO) be the amount of support you get: While a
> first-class arch will get faster fixes and a more stable dependency tree,
> other archs will be more "sloppy", for example by not blocking stable releases
> with their own RC bugs etc.
Yeah, a completely one-way relationship: no issue on second-class would
> If this can be fulfilled, I don't think being a second-class arch will be such
> a big deal. Not sure how far Debian is from this goal, but I can understand
> that many DDs and DMs would rather invest their time into projects they have a
> stake in, rather than hardware they don't (or don't want to?) understand.
Yes, x32 suffers from needing obscure and hard to get hardware. :)
. The vast majority of security issues are non arch dependent, so blindly
tracking and building first-class security updates gets us nearly all the
way, reducing the work to babysitting buildds and looking into FTBFSes or
yet another whole-new-language-ecosystem getting allowed into stable.
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄⠀⠀⠀⠀ to the city of his birth to die.