On Wed, 18 Mar 2020 09:54:42 -0500 William Hubbs <willi...@gentoo.org> wrote:
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
>
> Thanks,
I'm just gonna say I disagree with this proposal as stated.
Stability and arch support, for the purposes of QA, should be based on
demonstrated evidence.
Not speculation ( which noarch inherently is ).
I'd be "OK" with a provisional flag that indicates a package /should/
be architecture independent, but it should be as an optional
enhancement for users on minor arches who want to minimize their
fussing with keywords.
But KEYWORDS imo, should be a graph of demonstrated evidence, otherwise
it pretty much makes the purpose of arch testing redundant.
And yes, even vanilla perl code can have arch dependent behaviour.
( I myself fell prey to pack() having some behavioural changes based on
the users 32 vs 64bitness )
However, what I propose isn't something you can "hack in" to an
existing EAPI's tree.
You'd likely need an EAPI enhancement to implement this the way I'd
imagine.
In short:
- An Ebuild should still have KEYWORDS that indicate
- What it has been tested to work on
- What it has been evidentially supported on
- But an Ebuild *could* have a variable that indicates
- That in the absence of good testing and evidence, it is
*expected* to work on all arches.
- End users could be provided tools to *permit* the latter class
to be installed on their system based on the speculation
- But it would still be "out of scope" for users who want and demand
a tested, predictable, quality, stable system.
Anything else is just weakening our quality assurance for our users,
in order to pander to developer ease.
pgp1kAuQMVnfp.pgp
Description: OpenPGP digital signature
