Re: [gentoo-dev] rfc: noarch keyword

[Kent Fredric]

On Wed, 18 Mar 2020 09:54:42 -0500
William Hubbs <williamh@g.o> 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.