Re: [gentoo-dev] GLEP 22: New "keyword" system to incorporate various userlands/kernels/archs

[Olivier Crête]

Hi,

One thing that I find missing from this discussion is the actual meaning
of the keywords. Currently, when a package is marked stable, it means
that not only it compiled on the platform, but that it was also tested
by a real human being and that it (most of the time) it has been (we
hope) tested by many others without problem. The original GLEP22
proposal changes this, since the various "variables" are not truly
orthogonal, we end up with many many untested situations. 

If we want to support a very large number of hardware/software
combinations we have to either decide that we want to keep the same
level of QA and then test on every possibility and mark each one or
decide to change the level of QA and go for a debianization (if it
compiles, its ok) or an even looser system. For all its deficiencies,
rac's proposal seems like the only sane way to do this. And it would
allow for for much more diversified QA information, so we could record
different information from the results of a tinderbox to the number of
users using it. But this is very heavy to do. As a short term solution,
we could instead go with "multi-part" keywords (stuff like
x86:linux:gnu:glibc or i386-pc-linux-gnu (why not use standardised that
if we do that?)). Those keywords can always be later used to fill a
database.

This said, how much effort are we ready to put into satisfying what will
probably be a very very small number of users. I have the feeling that
almost all non-linux uses are purely academic (proving it can be done).
There is very little demand or use for gentoo outside the Linux world
(maybe except for macosx and that's just one more keyword), and no
proper solution has been proposed. So my conclusion on this is that for
the time being, we should stay with the current keywording system and
maybe add two or three more.

Olivier
tester@g.o

On Wed, 2004-03-17 at 00:12, Grant Goodyear wrote:
> Okay, here's a consolidation of the various comments about GLEP 22.
>
> The first comment, by Method, pointed out the most significant flaw in
> my proposal: the ARCH, LIBC, KERNEL, and USERLAND variables are not
> orthogonal (to use rac's term), so if ARCH lists x86 and ppc while
> KERNEL lists linux and obsd, how to we address the fact that obsd/ppc is
> not, in fact, a valid combination?
>
> I'm going to ignore a large thread of messages that discuss how
> sensitive alternative arch's are to requiring package patches to compile
> and/or function properly, other than to note that with the large number
> of possible ARCH/LIBC/KERNEL/USERLAND permutations even just enumerating
> the patches might end up being a tad hairy.  There was also a thread
> suggesting that packages should not, in general, be marked stable unless
> it is supported on all archs (or whatever).
>
> Drake Wyrm noted that the proposed system allowed people to test new
> permutations that might just work.  That sort of ability is something we
> should probably strive to maintain in whatever our ultimate solution
> should turn out to be.
>
> Rac has suggested a simple, if rather draconian, solution, which is to
> just let the explosion of keywords to occur, but get them out of the
> ebuilds.  His suggestion is to provide a database (maintained external
> to the ebuilds, perhaps even external to the users' systems) that uses a
> five-dimensional (arch/os/libc/kernel/ebuild-version) key to determine
> whether or not an ebuild should be built.
>
> I would prefer a somewhat more elegant approach than rac's brute-force
> database, if I could only think of one.  Any other thoughts out there?
-- 
Olivier Crête
tester@g.o
Gentoo Developer