Re: [Stretch] Status for architecture qualification

Niels Thykier <[email protected]> Sun, 5 Jun 2016 14:46:53 +0000
Newsgroups	gmane.linux.debian.ports.mips
Message-ID	<c65f907f-c03f-1b98-fd7f-c35d1be0f102__6604.10080240599$1465138116$gmane$org@thykier.net>
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
signature.asc (application/pgp-signature, 801 B)