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?
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).
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;
* creating a mini testing/stable suite based on debian-ports.org?
where maybe only the core packages are candidates to migrate.
[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,
--
Steven Chamberlain
steven@pyro.eu.org
Attachment:
signature.asc
Description: Digital signature