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

[Joshua Brindle]

relavent conversation between grant and I for public consumption.....


[16:24] <g2boojum> The best solution I had come up with so far was to 
add ARCH, USERLAND, KERNEL, and LIBC environment variables that would 
exist in concert with KEYWORDS.  Of course, that approach would mean 
listing each individually.  On the other hand, having reasonable 
defaults for the various variables might make that simpler.
[16:26] <g2boojum> I really need to think about this problem more 
systematically, but I haven't worked up the gumption to do so just yet.

[16:27] <Method> but what about combinations.. ie: something works with 
linux, ppc x86, glibc; obsd, x86, obsd-libc what are the valid 
variables. Since ARCH lists x86 and ppc does portage think that obsd/ppc 
is a valid combination (but it's not in reality)
[16:30] <Method> maybe metakeywords
[16:31] <Method> so openbsd automatically pulls in obsd OS, all archs's 
obsd supports, obsd-libc
[16:31] <Method> and then specific exceptions can be disabled

[16:32] <g2boojum> I was thinking that an ebuild might have ARCH=~ppc if 
the ebuild is in testing for ppc using glibc/linux/gnu (which would be 
the defaults).  An ebuild that is stable on default x86-obsd might have 
ARCH=x86 USERLAND=bsd KERNEL=obsd (w/ libc=openbsd the default for that 
profile), or some such.  *Shrug*  Like I said, it still needs more thinking.
[16:33] <g2boojum> I also think the idea of metakeywords is going to be 
important, since a package that works on one bsd may work on all (in 
which case we want to use a single bsd USERLAND flag, or some such), or 
it may not (in which case freebsd might need to be specified somewhere). 
  Ugh.

[16:35] <Method> yea... it's complex and 90% of the devs aren't going to 
understand it so it needs to be robust and not overly sensitive


Grant Goodyear wrote:
> Dear all,
>   I've attached a GLEP that I've submitted that describes one method to
> handle the potential explosion of new keywords that will arise as we
> improve Gentoo support for non-linux systems.  I have no doubt that my
> proposal is deeply flawed, so constructive suggestions will be greatly
> appreciated.
>
> Thanks,
> g2boojum
>
>
> ------------------------------------------------------------------------
>
> GLEP: 22
> Title: New "keyword" system to incorporate various userlands/kernels/archs
> Version: $Revision: 1.1 $
> Last-Modified: $Date: 2004/03/07 02:20:32 $
> Author: Grant Goodyear <g2boojum@g.o>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 6-Mar-2004
> Post-History: 6-Mar-2004
>
> Credits
> =======
>
> This GLEP originated from the concerns that Daniel Robbins had with
> the *x86obsd* keyword, and his desire to make the KEYWORDS variable more
> "feature-rich".  Drobbins' original idea was that we should
> allow compound
> keywords such as gnu/x86, gnu/ppc, and macos/ppc (which would be explicit
> versions of the more familiar x86, ppc, and macos keywords).  Method noted
> that userland/arch failed to capture the full range of possibilities (what
> about a GNU userland on a BSD kernel+libc?), and
> the issue has languished due to a lack of reasonable solutions.
>
> Abstract
> ========
>
> As Gentoo branches out to support non-Linux and non-GNU systems (such
> as Hurd or the \*BSDs), the potential for an "explosion" of possible
> keywords becomes rather large, since each
> new userland/kernel/arch/whatever
> combination would require a new keyword.
> This GLEP proposes replacing the current
> KEYWORDS variable with four variables, ARCH, USERNAME, KERNEL, and LIBC,
> along with sensible defaults to keep the new system manageable.
>
> Motivation
> ==========
>
> Since the beginning, Gentoo Linux has been conceived as a "metadistribution"
> that combines remarkable flexibility with sensible defaults and exceptional
> maintainablilty.  The goal of the Gentoo-Alt_ project has been to extend that
> flexibility to include systems other than GNU/Linux.  For example, the author
> of this GLEP has been working to create a version_ of Gentoo that uses
> OpenBSD_ as the underlying kernel, userland, and libc.  OpenBSD_ supports
> a variety of different architectures, so, in principle, we would need a new
> *openbsd-arch* keyword for each supported architecture.  In fact, the situation
> is even more complicated, because the Gentoo-Alt_ project would eventually
> like
> to support the option of "mixing-and-matching" GNU/\*BSD/whatever userlands
> and libcs irrespective of the underlying kernel. (Debian_, for example
> has a similar BSD project_, except that they have replaced the
> BSD userland with a GNU userland.)  The net result is that we would need
> keywords that specified all possible permutations of arch, userland, kernel
> and libc.  Not fun.
>
> .. _Gentoo-Alt: http://www.gentoo.org/proj/en/gentoo-alt/index.xml
> .. _OpenBSD: http://www.openbsd.com
> .. _version: http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml
> .. _Debian: http://www.debian.org
> .. _project: http://www.debian.org/ports/netbsd/
>
> Specification
> =============
>
> New Variables
> -------------
>
> I suggest that we replace the single KEYWORDS variable in ebuilds
> with four separate variables: ARCH, USERLAND, LIBC, and KERNEL.
>
>     ARCH:
>         x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc
>     USERLAND:
>         gnu, bsd
>     LIBC:
>         glibc, openbsd, freebsd, netbsd, macosx
>     KERNEL:
>         linux, selinux, openbsd, freebsd, netbsd, macosx
>
> (The above examples are not meant to be complete.  Hurd, for example
> is not included because I know very little about Hurd.)
> For each variable the standard "-,-\*,~" prefixes would be allowed.
> Similarly, `/etc/make.conf` would have ACCEPT_ARCH, ACCEPT_USERLAND,
> ACCEPT_LIBC, and ACCEPT_KERNEL variables.
>
> Reasonable Defaults
> -------------------
>
> To keep this system manageable, we need sensible defaults. An ebuild
> that has missing USERLAND, KERNEL, or LIBC variables is provided
> with implicit USERLAND="gnu", KERNEL="linux", and/or LIBC="glibc"
> variables.  However, once a variable is explicitly added (such as
> KERNEL="openbsd"), the default is no longer assumed.  That is,
> one would need KERNEL="openbsd linux" if the ebuild is stable on
> both openbsd and linux kernels.
>
> The ARCH variable, on the other hand, does *not* have a default, per se.
> Instead, if no ARCH variable exists then portage would automatically
> add the ebuild's KEYWORD entries to ARCH.  Thus, all current ebuilds
> would still work without changes, allowing for a gradual transition
> to the new system as the new variables are needed.
>
> Profiles
> --------
>
> Along with an explosion of keywords comes a concomitant explosion
> of potential profiles.  The good news is that profiles show up only
> in a single directory, so an explosion there is easier to contain.
> I suggest an arch-kernel-userland-libc-version naming scheme, with
> the kernel-userland-libc terms defaulting to linux-gnu-glibc if
> absent.  (Yes, Chemists do tend to be fond of systematic naming
> systems.)
>
> One drawback to having a large number of profiles is that maintainance
> becomes a significant problem.  In fact, one could reasonably argue
> that the current number of profiles is already too many to be
> easily maintained.  One proposal that has been raised to simplify
> matters is the idea of stackable, or cascading, profiles, so that
> only differences between profiles would have to be maintained.
>
> Rationale
> =========
>
> The proposed new "keywording" system is far from elegant, which is
> a substantial drawback.  On the other hand, it is simple, it requires
> relatively minor changes (albeit ones that eventually would impact
> every ebuild in the portage tree), and the changes can be implemented
> gradually over time.
>
> Implementation
> ==============
>
> Implementation of this GLEP would divide into adding
> Portage functionality to support the new system and
> modifying ebuilds to
> comply with the new system.
> The Portage support involves hacking Portage
> to assemble and check a four-state
> arch-userland-kernel-libc variable instead of the simpler
> KEYWORD variable.  One might quibble over algorithmic issues, but
> the actual concept is pretty straightforward.  Rewriting ebuilds,
> on the other hand, is a massive undertaking.  Fortunately, it is
> also a process that can be done over whatever length of time is
> required, since "legacy" ebuilds should work with no changes.
>
>
> Backwards Compatibility
> =======================
>
> Backwards compatibility has already been addressed in some detail,
> with the stated goal being a system that would leave all current
> ebuilds in a still-functioning state after the portage modifications
> have been made.  However, we are already using an ARCH variable for
> some arcane purpose in Portage, and that issue would still need to
> be resolved.
>
>
> Copyright
> =========
>
> This document is licensed under the Creative Commons - Attribution / Share
> Alike license. (http://creativecommons.org/licenses/by-sa/1.0)


--
gentoo-dev@g.o mailing list