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 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 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
[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
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
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 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
[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
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? 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/ pgpfWJJfNdLak.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On Fri, 10 Oct 2008 09:15:16 +0200 Fabian Groffen [EMAIL PROTECTED] 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 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 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
[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
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. -- 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
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
