Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
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
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
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 <[EMAIL PROTECTED]> 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
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On 13-10-2008 15:27:10 +0100, Ciaran McCreesh wrote:
> On Mon, 13 Oct 2008 06:16:01 +0100
> Steve Long <[EMAIL PROTECTED]> 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
On Mon, 13 Oct 2008 06:16:01 +0100 Steve Long <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On Fri, 10 Oct 2008 17:56:37 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: > On Fri, 10 Oct 2008 14:48:19 +0200 > Fabian Groffen <[EMAIL PROTECTED]> 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. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On Fri, 10 Oct 2008 14:48:19 +0200 Fabian Groffen <[EMAIL PROTECTED]> 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
On 10-10-2008 14:40:13 +0200, Diego 'Flameeyes' Pettenò wrote: > Fabian Groffen <[EMAIL PROTECTED]> 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] Re: [RFC] New keywords for non-Gentoo Linux platforms
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] Re: [RFC] New keywords for non-Gentoo Linux platforms
On Fri, 10 Oct 2008 00:16:10 + (UTC) Duncan <[EMAIL PROTECTED]> wrote: > Marius Mauch <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Fri, > 10 Oct 2008 00:05:00 +0200: > > > On Thu, 9 Oct 2008 20:11:01 +0200 > > Fabian Groffen <[EMAIL PROTECTED]> 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
