[gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

[gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

[Fabian Groffen]

Hi all,

In the Prefix project we support a bunch of Linux and non-Linux
platforms, for which we use GLEP53-style[1] keywords.  The current list
of keywords known in Prefix are (in no particular order):

	ppc-aix
	x86-freebsd
	ia64-hpux
	hppa-hpux
	x86-interix
	mips-irix
	amd64-linux
	x86-linux
	ppc-macos
	x86-macos
	x86-netbsd
	ppc-openbsd
	x86-openbsd
	x64-openbsd
	sparc-solaris
	sparc64-solaris
	x64-solaris
	x86-solaris
	x86-winnt

Most notably, in Prefix all keywords are full GLEP53 style, which
results in e.g. amd64-linux.  We did this on purpose, because in Prefix
we don't necessarily are on Gentoo Linux.  We also chose to expand fbsd,
nbsd and obsd to their long variants, mainly because the short variants
might clash in the future, for e.g. OpenBSD, OliveBSD or PicoBSD,
polyBSD or DragonflyBSD, DesktopBSD.  (At some point we were a bit
over-enthausiastic.)

I would like to hear some opinions on the keywords in general, as well
as the particular problem of having Gentoo Linux, and a Linux supported
by Gentoo Prefix.  Right now there is just the difference of "-linux"
appended, however this is not the clearest distinction between the two.
Perhaps using KEYWORDS for Prefix keywords is not the best thing to do,
and should we use something like PREFIX_KEYWORDS?


[1] http://www.gentoo.org/proj/en/glep/glep-0053.html

-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

[Marius Mauch]

On Thu, 9 Oct 2008 20:11:01 +0200
Fabian Groffen <grobian@gentoo.org> wrote:

> 	amd64-linux
> 	x64-openbsd
> 	x64-solaris

Is there a special reason why you're using "x64" instead of "amd64" in
those cases? (IMO x64 is the most stupid name for the x86_64
architecture)

Marius

[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Duncan]

Marius Mauch <genone@gentoo.org> posted
20081010000500.b405d25b.genone@gentoo.org, excerpted below, on  Fri, 10
Oct 2008 00:05:00 +0200:

> On Thu, 9 Oct 2008 20:11:01 +0200
> Fabian Groffen <grobian@gentoo.org> wrote:
> 
>> 	amd64-linux
>> 	x64-openbsd
>> 	x64-solaris
> 
> Is there a special reason why you're using "x64" instead of "amd64" in
> those cases? (IMO x64 is the most stupid name for the x86_64
> architecture)

AFAIK, that's not amd64/x86_64, but rather ia64, aka itanic aka itanium.  
At least, that's how I'd interpret them since I've seen that abbreviation 
made before, particularly since there's already amd64 in context.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Marius Mauch]

On Fri, 10 Oct 2008 00:16:10 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Marius Mauch <genone@gentoo.org> posted
> 20081010000500.b405d25b.genone@gentoo.org, excerpted below, on  Fri,
> 10 Oct 2008 00:05:00 +0200:
> 
> > On Thu, 9 Oct 2008 20:11:01 +0200
> > Fabian Groffen <grobian@gentoo.org> wrote:
> > 
> >> 	amd64-linux
> >> 	x64-openbsd
> >> 	x64-solaris
> > 
> > Is there a special reason why you're using "x64" instead of "amd64"
> > in those cases? (IMO x64 is the most stupid name for the x86_64
> > architecture)
> 
> AFAIK, that's not amd64/x86_64, but rather ia64, aka itanic aka
> itanium. At least, that's how I'd interpret them since I've seen that
> abbreviation made before, particularly since there's already amd64 in
> context.

No, x64 is the marketing name Microsoft made up for x86_64 (aka amd64,
ia32e and Intel 64), as "Windows for x86_64" doesn't sound that sexy,
and was later adopted by Sun and others. 
ia64/Itanium doesn't have any other alias names AFAIK.

Marius

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Fabian Groffen]

On 10-10-2008 04:21:23 +0200, Marius Mauch wrote:
> > >> 	amd64-linux
> > >> 	x64-openbsd
> > >> 	x64-solaris
> > > 
> > > Is there a special reason why you're using "x64" instead of "amd64"
> > > in those cases? (IMO x64 is the most stupid name for the x86_64
> > > architecture)
> > 
> > AFAIK, that's not amd64/x86_64, but rather ia64, aka itanic aka
> > itanium. At least, that's how I'd interpret them since I've seen that
> > abbreviation made before, particularly since there's already amd64 in
> > context.
> 
> No, x64 is the marketing name Microsoft made up for x86_64 (aka amd64,
> ia32e and Intel 64), as "Windows for x86_64" doesn't sound that sexy,
> and was later adopted by Sun and others. 
> ia64/Itanium doesn't have any other alias names AFAIK.

We simply found that:
- amd64 is misleading
- em64t would be more to the point for some?
- x64 is what the vendors (Apple, Sun) advertise themselves
- amd64 doesn't make any sense for a Mac
- x64 is more like x86, whereas the complement of amd64 would more be
  i386 or ia32, but we wanted to avoid x86_64, x8664, so x64
- we were changing keywords anyway


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

[Michael Haubenwallner]

On Thu, 2008-10-09 at 20:11 +0200, Fabian Groffen wrote:

> 	ia64-hpux

There's one thing to say for this platform to avoid later confusion:

'ia64-hpux' is the keyword for 32bit on that platform.
'ia64w-hpux' would be the 64bit keyword (not in prefix-tree yet).

This might seem confusing, but is the way HP does for various reasons.

HP-UX is the only OS I know that does multilib on the ia64 CPU, and the
default compiler output is 32bit without any additional switch.

I can provide more details if necessary.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

Fabian Groffen <grobian@gentoo.org> writes:

> - x64 is what the vendors (Apple, Sun) advertise themselves

Err I'm sure I haven't seen any x64 in the documentation or
advertisement of my MacBook Pro, are you sure _Apple_ uses that totally
bogus name?

Anyway, em64t might be better, but then again you're to the same point:
an Opteron using an Intel name? I think amd64 is totally fine since it's
the first commercial name it got by uh, those who introduced it, I
guess, but the only thing I don't ever want to see officially is
endorsing the x64 commercial speak.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Fabian Groffen]

On 10-10-2008 14:40:13 +0200, Diego 'Flameeyes' Pettenò wrote:
> Fabian Groffen <grobian@gentoo.org> writes:
> 
> > - x64 is what the vendors (Apple, Sun) advertise themselves
> 
> Err I'm sure I haven't seen any x64 in the documentation or
> advertisement of my MacBook Pro, are you sure _Apple_ uses that totally
> bogus name?

Ehm, no.  So I must have been confused.

> Anyway, em64t might be better, but then again you're to the same point:
> an Opteron using an Intel name? I think amd64 is totally fine since it's
> the first commercial name it got by uh, those who introduced it, I
> guess, but the only thing I don't ever want to see officially is
> endorsing the x64 commercial speak.

Whatever.  Some of you seem to have some quite agressive dislikement to
it.  In the end it's just a name/tag.  I guess I could live with
anything, including c3p0.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

[Jeremy Olexa]

Fabian Groffen wrote:
<snip>
> Most notably, in Prefix all keywords are full GLEP53 style, which
> results in e.g. amd64-linux.  We did this on purpose, because in Prefix
> we don't necessarily are on Gentoo Linux.  We also chose to expand fbsd,
> nbsd and obsd to their long variants, mainly because the short variants
> might clash in the future, for e.g. OpenBSD, OliveBSD or PicoBSD,
> polyBSD or DragonflyBSD, DesktopBSD.  (At some point we were a bit
> over-enthausiastic.)
> 
> I would like to hear some opinions on the keywords in general, as well
> as the particular problem of having Gentoo Linux, and a Linux supported
> by Gentoo Prefix.  Right now there is just the difference of "-linux"
> appended, however this is not the clearest distinction between the two.
> Perhaps using KEYWORDS for Prefix keywords is not the best thing to do,
> and should we use something like PREFIX_KEYWORDS?


Ignoring the bit about how to name the keywords.. ;)

I am undecided about Prefix keywords in the normal KEYWORDS variable. In 
particular, we are overloading the -linux keyword to mean that it will 
run on any linux that Gentoo Prefix supports. This includes, Gentoo, 
RHEL, SLES, FreeMint, $OTHER.

Is there any problem with "overloading" the keywords like that? If not, 
then it shouldn't be a problem to keep prefix keywords in the KEYWORDS 
field. OTOH, I don't think we should add another variable to ebuilds.

Thoughts?

-Jeremy

[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]

On Fri, 10 Oct 2008 09:15:16 +0200
Fabian Groffen <grobian@gentoo.org> wrote:

> > No, x64 is the marketing name Microsoft made up for x86_64 (aka
> > amd64, ia32e and Intel 64), as "Windows for x86_64" doesn't sound
> > that sexy, and was later adopted by Sun and others. 
> > ia64/Itanium doesn't have any other alias names AFAIK.
> 
> We simply found that:
> - amd64 is misleading
> - em64t would be more to the point for some?
> - x64 is what the vendors (Apple, Sun) advertise themselves
> - amd64 doesn't make any sense for a Mac
> - x64 is more like x86, whereas the complement of amd64 would more be
>   i386 or ia32, but we wanted to avoid x86_64, x8664, so x64

why?  x86_64 is the proper name for the architecture. (includes amd64,
em64t, and via isaiah)

your bikeshed though, i guess.  you can paint it whatever you want.  ;)

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Marius Mauch]

On Fri, 10 Oct 2008 14:48:19 +0200
Fabian Groffen <grobian@gentoo.org> wrote:

> Whatever.  Some of you seem to have some quite agressive dislikement
> to it.  In the end it's just a name/tag.  I guess I could live with
> anything, including c3p0.

Well, while I dislike x64 I'm more concerned about using different
names (amd64 and x64) for the same architecture (same would apply if
you had used i386 or ia32 in some cases instead of x86) and was just
checking if there was any functional reason for that difference.

Marius

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Robert Bridge]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

On Fri, 10 Oct 2008 17:56:37 +0200
Marius Mauch <genone@gentoo.org> wrote:

> On Fri, 10 Oct 2008 14:48:19 +0200
> Fabian Groffen <grobian@gentoo.org> wrote:
> 
> > Whatever.  Some of you seem to have some quite agressive dislikement
> > to it.  In the end it's just a name/tag.  I guess I could live with
> > anything, including c3p0.
> 
> Well, while I dislike x64 I'm more concerned about using different
> names (amd64 and x64) for the same architecture (same would apply if
> you had used i386 or ia32 in some cases instead of x86) and was just
> checking if there was any functional reason for that difference.

I would agree with this.

As a user coming to the project, x64 is NOT the same arch as amd64, it
has a different name! Select one name for the arch, and use it
everywhere. Consistent naming is more important than having the name
absolutely technically correct.

And seeing as Gentoo uses amd64 for all those arches in the main tree
with minimal problems, I personally would vote for using amd64 in -alt
to retain consistency with the rest of Gentoo.

Just my 2 cents.

Rob.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Steve Long]

Jeremy Olexa wrote:

> Fabian Groffen wrote:
> <snip>
>> Most notably, in Prefix all keywords are full GLEP53 style, which
>> results in e.g. amd64-linux.  We did this on purpose, because in Prefix
>> we don't necessarily are on Gentoo Linux.  We also chose to expand fbsd,
>> nbsd and obsd to their long variants, mainly because the short variants
>> might clash in the future, for e.g. OpenBSD, OliveBSD or PicoBSD,
>> polyBSD or DragonflyBSD, DesktopBSD.  (At some point we were a bit
>> over-enthausiastic.)
>> 
>> I would like to hear some opinions on the keywords in general, as well
>> as the particular problem of having Gentoo Linux, and a Linux supported
>> by Gentoo Prefix.

Would it not be simpler just to say the keyword can be from 1 to 4
hypen-separated parts, 1 as-is (in both GLEPS) 2 as GLEP 53, 3 with libc
change, and 4 with non-default userland as per GLEP22 (perhaps change the
order to be more intuitive, if you think it would be better)?

>> Right now there is just the difference of "-linux" 
>> appended, however this is not the clearest distinction between the two.
>> Perhaps using KEYWORDS for Prefix keywords is not the best thing to do,
>> and should we use something like PREFIX_KEYWORDS?
> 
> Ignoring the bit about how to name the keywords.. ;)
> 
> I am undecided about Prefix keywords in the normal KEYWORDS variable. In
> particular, we are overloading the -linux keyword to mean that it will
> run on any linux that Gentoo Prefix supports. This includes, Gentoo,
> RHEL, SLES, FreeMint, $OTHER.
> 
> Is there any problem with "overloading" the keywords like that? If not,
> then it shouldn't be a problem to keep prefix keywords in the KEYWORDS
> field. OTOH, I don't think we should add another variable to ebuilds.
> 
> Thoughts?
> 
Wrt to the variable thing, I agree the specification of prefix is orthogonal
to the spec of an EAPI. Orthogonality [at least in sw terms] doesn't just
mean "nothing to do with it whatsoever," or it wouldn't apply to the
software in question.

Unless someone can say what using PROPERTIES=prefix would break, I'd go with
that. It's a /classic/ usage of that variable, as it's simply a boolean;
PROPERTIES is well-defined and I'm hoping all the manglers support it. It'd
be great to see the prefix branch finally merged so we all get to play with
it.

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

On Mon, 13 Oct 2008 06:16:01 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Unless someone can say what using PROPERTIES=prefix would break, I'd
> go with that. It's a /classic/ usage of that variable, as it's simply
> a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
> support it. It'd be great to see the prefix branch finally merged so
> we all get to play with it.

It would break. Prefix ebuilds won't work unless ED is set, and a non
PROPERTIES aware or non-prefix-property aware package manager won't set
ED. Unless prefix is reimplemented to require no package manager
changes for the install to / case, PROPERTIES is out.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Fabian Groffen]

On 13-10-2008 15:27:10 +0100, Ciaran McCreesh wrote:
> On Mon, 13 Oct 2008 06:16:01 +0100
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > Unless someone can say what using PROPERTIES=prefix would break, I'd
> > go with that. It's a /classic/ usage of that variable, as it's simply
> > a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
> > support it. It'd be great to see the prefix branch finally merged so
> > we all get to play with it.
> 
> It would break. Prefix ebuilds won't work unless ED is set, and a non
> PROPERTIES aware or non-prefix-property aware package manager won't set
> ED. Unless prefix is reimplemented to require no package manager
> changes for the install to / case, PROPERTIES is out.

Just to comment on this possibility; I see an option, given the
definition of ED and EROOT to do Prefix without them, by e.g. using
${D}${EPREFIX} instead of ${ED} as shorthand.  When ${EPREFIX} would be
unset, this would result in simple ${D}, which is "backwards
compatible".  This is not all what is necessary, but a big deal of it.

Question here, however, is whether this is worth it.  Personally, I
prefer the shorthands, as they give a lot of readability.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Michael Haubenwallner]

On Mon, 2008-10-13 at 19:59 +0200, Fabian Groffen wrote:
> On 13-10-2008 15:27:10 +0100, Ciaran McCreesh wrote:
> > On Mon, 13 Oct 2008 06:16:01 +0100
> > Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > > Unless someone can say what using PROPERTIES=prefix would break, I'd
> > > go with that. It's a /classic/ usage of that variable, as it's simply
> > > a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
> > > support it. It'd be great to see the prefix branch finally merged so
> > > we all get to play with it.
> > 
> > It would break. Prefix ebuilds won't work unless ED is set, and a non
> > PROPERTIES aware or non-prefix-property aware package manager won't set
> > ED. Unless prefix is reimplemented to require no package manager
> > changes for the install to / case, PROPERTIES is out.
> 
> Just to comment on this possibility; I see an option, given the
> definition of ED and EROOT to do Prefix without them, by e.g. using
> ${D}${EPREFIX} instead of ${ED} as shorthand.  When ${EPREFIX} would be
> unset, this would result in simple ${D}, which is "backwards
> compatible".  This is not all what is necessary, but a big deal of it.
> 
> Question here, however, is whether this is worth it.  Personally, I
> prefer the shorthands, as they give a lot of readability.

Could it also work to initialize them in profile.bashrc if they are
unset?

Something like
        : ${EPREFIX=}
        : ${ED=${D}}
        : ${EROOT=${ROOT}}

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] Re: Re: [RFC] New keywords for non-Gentoo Linux platforms

[Steve Long]

Michael Haubenwallner wrote:
> Fabian Groffen wrote:
>> Ciaran McCreesh wrote:
>> > Steve Long wrote:
>> > > Unless someone can say what using PROPERTIES=prefix would break, I'd
>> > > go with that. It's a /classic/ usage of that variable, as it's simply
>> > > a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
>> > > support it. It'd be great to see the prefix branch finally merged so
>> > > we all get to play with it.
>> > 
>> > It would break. Prefix ebuilds won't work unless ED is set, and a non
>> > PROPERTIES aware or non-prefix-property aware package manager won't set
>> > ED. Unless prefix is reimplemented to require no package manager
>> > changes for the install to / case, PROPERTIES is out.

Nonsense; we just need some bash changes to integrate it iff we want to
allow prefix ebuilds into the main tree; we're a while away from actually
being at the stage where that would be feasible, even if it were desired.
By the time we do get there, we should be able to fulfil your last
condition, given a sane bash implementation for the mangler in question.

TBH I'm not really worried about alternative manglers atm; they can catch up
w/e afaic. IIRC PROPERTIES are part of EAPI-2, so one would hope they've
already done that by now.

>> 
>> Just to comment on this possibility; I see an option, given the
>> definition of ED and EROOT to do Prefix without them, by e.g. using
>> ${D}${EPREFIX} instead of ${ED} as shorthand.  When ${EPREFIX} would be
>> unset, this would result in simple ${D}, which is "backwards
>> compatible".  This is not all what is necessary, but a big deal of it.
>> 
>> Question here, however, is whether this is worth it.  Personally, I
>> prefer the shorthands, as they give a lot of readability.
>
Yeah the shorthands are nice, agreed. Ideally we wouldn't need to change
anything in the ebuild though. (I appreciate we're a while away from there,
but if we can at least get the ones which go via emake and econf, that's a
start. We can worry about {scons,distutils,..} later; pro-audio have a nice
exteutils.eclass we can 'borrow' for a start ;)

From the prefix docs, the only place D should be retained over ED is in a
DESTDIR="$D" (or "${D}") when configure --prefix=.. has been run. Is that
correct?
 
> Could it also work to initialize them in profile.bashrc if they are
> unset?
> 
> Something like
>         : ${EPREFIX=}
>         : ${ED=${D}}
>         : ${EROOT=${ROOT}}
> 
That would work yeah, though I think it would be better if we just
integrated that into ebuild.sh. We can check PROPERTIES to see if prefix is
in there, and then enable additional logic, and eg use a different PATH for
external helpers (most of which we can do internally in any case.) I
realise the latter is happening already, but if we're integrating, it
should be happening in the mainline code when applicable, imo. (Not saying
that is the applicable case, just that we can change w/e you see fit.)

Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

[Michael Haubenwallner]

On Thu, 2008-10-09 at 20:11 +0200, Fabian Groffen wrote:

> 	sparc-solaris
> 	sparc64-solaris
> 	x64-solaris
> 	x86-solaris

> Perhaps using KEYWORDS for Prefix keywords is not the best thing to do,
> and should we use something like PREFIX_KEYWORDS?

Maybe there is one thing we should consider:
Since the Solaris kernel is Open now (=OpenSolaris), one could have the
strange idea of adding some "sys-kernel/solaris-sources-2.11.ebuild", to
build some distribution eventually called "Gentoo Solaris", which might
be comparable to Nexenta[1], which uses Debian's APT AFAICS.

As "Gentoo Solaris" would not be the same as "Gentoo Prefix on Solaris",
it should not share the *-solaris keywords used for Prefix via the same
KEYWORDS-setting.

For me, this is a (maybe strange, but valid) reason for something like
PREFIX_KEYWORDS.

[1] http://www.nexenta.org/

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Tiziano Müller]

Michael Haubenwallner wrote:

> 
> On Thu, 2008-10-09 at 20:11 +0200, Fabian Groffen wrote:
> 
>> sparc-solaris
>> sparc64-solaris
>> x64-solaris
>> x86-solaris
> 
>> Perhaps using KEYWORDS for Prefix keywords is not the best thing to do,
>> and should we use something like PREFIX_KEYWORDS?
> 
> Maybe there is one thing we should consider:
> Since the Solaris kernel is Open now (=OpenSolaris), one could have the
> strange idea of adding some "sys-kernel/solaris-sources-2.11.ebuild", to
> build some distribution eventually called "Gentoo Solaris", which might
> be comparable to Nexenta[1], which uses Debian's APT AFAICS.
Already on my agenda once I've got internet at home again, my server up and
running and all my current bugs squashed.

> 
> As "Gentoo Solaris" would not be the same as "Gentoo Prefix on Solaris",
> it should not share the *-solaris keywords used for Prefix via the same
> KEYWORDS-setting.
what about a new generic schema like: CPU-OS[-prefix] with the possibility
of shell expansion in KEYWORDS to have something like this:
KEYWORDS="{x86,sparc}-linux" or KEYWORDS="linux: x86 sparc ppc freebsd: x86
sparc solaris-prefix: sparc" ?

Cheers,
Tiziano

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Fabian Groffen]

On 21-10-2008 16:09:12 +0200, Tiziano Müller wrote:
> > As "Gentoo Solaris" would not be the same as "Gentoo Prefix on Solaris",
> > it should not share the *-solaris keywords used for Prefix via the same
> > KEYWORDS-setting.
> what about a new generic schema like: CPU-OS[-prefix] with the possibility
> of shell expansion in KEYWORDS to have something like this:
> KEYWORDS="{x86,sparc}-linux" or KEYWORDS="linux: x86 sparc ppc freebsd: x86
> sparc solaris-prefix: sparc" ?

Such thing sort of solve the problem with multi-line keywords, but might
complicate matters which do not justify the cosmetic advantage?

Having prefix as tag in a keyword isn't such a bad idea, perhaps, since
one should really see them as separate from non-prefixed in certain
cases.  So far we just solved problems via the profiles or newly
introduced prefix? conditionals.


-- 
Fabian Groffen
Gentoo on a different level