Steven Chamberlain: > Hi, > Hi, > John Paul Adrian Glaubitz wrote: >> I have invested lots of time and effort to get sparc64 into a usable state in Debian. >> We are close to 11.000 installed packages. Missing packages include Firefox, >> Thunderbird/Icedove, golang and LibreOffice to name the most important ones. > > Is there some way to define 'core'[0] packages as blockers for testing > migration, and arch release qualification; but other packages not? > There is no current definition and I doubt it will be trivial to agree on a definition. Also, the moment you want to keep the set self-contained (by including build-depends) it very easily explodes unless you patch packages to disable "optional" features. > Many of these ports would be useful if just a base system was released, > and preferably having stable/security updates for that part (otherwise > it is difficult for users to try it, developers to work on it, or DSA to > support buildds for it; all of which are limitations on ports' further > growth). > Assuming we use your definition as basis, you probably also want the packages necessary to support a DSA maintained buildd. Otherwise it seems it fail one of your own proposed requirements. > Trying to have *every* package build and stay built on every port, and > supported for the lifetime of stable, is a lot of work without much > purpose sometimes. And it's unreasonable for any one port to block > testing migration of a package on all arches, unless it is something > really essential. > > This might be done either: > * in the official archive, with relaxed rules for testing migration > and more frequently de-crufting of out-of-date packages; I suspect this will be a lot of work and an uphill battle as the our current tooling is not really written for this case. At the very least, I fear a lot of extra special cases in Britney that I cannot easily deal with. > * creating a mini testing/stable suite based on debian-ports.org? > where maybe only the core packages are candidates to migrate. > At least short term, this probably a lot more tractable. I am happy to provide help with setting up a Britney instance for ports. Though we would need some way to provide a architecture specific version of the "core" packages. > [0]: I'd define core packages as everything needed to install, boot, and > then build packages on that arch. The rebootstrap project gives us some > idea of what those are; but add to that the kernel and any bootloaders. > Being able to rebootstrap, should be part of the arch release > qualification anyway IMHO. > > Regards, > Hmm, the rebootstrap idea is interesting as a new requirement. I will look into it. Thanks, ~Niels
Attachment:
signature.asc
Description: OpenPGP digital signature