Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
[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[1] 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 block first-class. > 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. :) Meow! [1]. 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.
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Hi Adrian 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 (although they should not be the norm). There will always be such packages, as proven by many that are available on first-class archs but not on second-class ones (protobuf springs to mind: https://buildd.debian.org/status/package.php?p=protobuf). 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). 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. 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. Regards, Greg
Appuntamento con il nuovo ciclo di lectiones magistrales di AFIP International
Se non visualizzi correttamente questo messaggio, clicca qui: http://www.mailant.it/nl.aspx?idp=14715=101034=0E2FA94E582CE1334891A9A307CD9E07B21F6098=6421462=40ECA39B8D5EAA85F045A3873ED68EDA53630FFB
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Hello! On 12/9/18 3:18 PM, Matthias Klose wrote: > To me it looks sometimes that Debian is used for testing by upstream, and for > that the mips architectures don't need to be release architectures. A note on this: If you decide to move MIPS to Debian Ports, you will make the port unusable to most users as Debian Ports has a rather rudimentary FTP archive setup which has some annoying side effects. There is no support for a testing release, there is no support for cruft and the FTP maintainers will eventually remove any MIPS-only packages from the Debian archive which don't build on other architectures which usually affects packages like boot loaders meaning that it will no longer be easily possible to build the debian-installer package and consequently build installation images. The 32-bit PowerPC port lost quite a number of users because of this change. Not because the port was not healthy but because people want to be able to install a stable release. Debian unfortunately doesn't have really good support for Tier II architectures, it's either release or something based on unstable that requires extra elbow grease from both users and maintainers. Please also keep in mind that removing MIPS from the list of release architectures would mean one less open platform on which Debian is supported. Neither anything based on ARM, x86 or IBM Z provides a true open platform due to the proprietary nature of these architectures. There are some efforts in this regard on IBM POWER, but the hardware is still rather expensive, unfortunately. I do hope that RISC-V will catch up in the future though. I also think that the broad architecture support is one of the selling points of Debian and if we were to limit Debian's architecture support to just ARM, x86, POWER and IBM Z, I fear that Debian would more and more be turned into a mere development project for Ubuntu and other derivatives rather than being an operating system of its own. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
