* [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms @ 2008-10-09 18:11 Fabian Groffen 2008-10-09 22:05 ` Marius Mauch ` (3 more replies) 0 siblings, 4 replies; 20+ messages in thread From: Fabian Groffen @ 2008-10-09 18:11 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms 2008-10-09 18:11 [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms Fabian Groffen @ 2008-10-09 22:05 ` Marius Mauch 2008-10-10 0:16 ` [gentoo-dev] " Duncan 2008-10-10 8:56 ` [gentoo-dev] " Michael Haubenwallner ` (2 subsequent siblings) 3 siblings, 1 reply; 20+ messages in thread From: Marius Mauch @ 2008-10-09 22:05 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-09 22:05 ` Marius Mauch @ 2008-10-10 0:16 ` Duncan 2008-10-10 2:21 ` Marius Mauch 0 siblings, 1 reply; 20+ messages in thread From: Duncan @ 2008-10-10 0:16 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-10 0:16 ` [gentoo-dev] " Duncan @ 2008-10-10 2:21 ` Marius Mauch 2008-10-10 7:15 ` Fabian Groffen 0 siblings, 1 reply; 20+ messages in thread From: Marius Mauch @ 2008-10-10 2:21 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-10 2:21 ` Marius Mauch @ 2008-10-10 7:15 ` Fabian Groffen 2008-10-10 12:40 ` Diego 'Flameeyes' Pettenò 2008-10-10 15:21 ` Ryan Hill 0 siblings, 2 replies; 20+ messages in thread From: Fabian Groffen @ 2008-10-10 7:15 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-10 7:15 ` Fabian Groffen @ 2008-10-10 12:40 ` Diego 'Flameeyes' Pettenò 2008-10-10 12:48 ` Fabian Groffen 2008-10-10 15:21 ` Ryan Hill 1 sibling, 1 reply; 20+ messages in thread From: Diego 'Flameeyes' Pettenò @ 2008-10-10 12:40 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-10 12:40 ` Diego 'Flameeyes' Pettenò @ 2008-10-10 12:48 ` Fabian Groffen 2008-10-10 15:56 ` Marius Mauch 0 siblings, 1 reply; 20+ messages in thread From: Fabian Groffen @ 2008-10-10 12:48 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-10 12:48 ` Fabian Groffen @ 2008-10-10 15:56 ` Marius Mauch 2008-10-10 16:13 ` Robert Bridge 0 siblings, 1 reply; 20+ messages in thread From: Marius Mauch @ 2008-10-10 15:56 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-10 15:56 ` Marius Mauch @ 2008-10-10 16:13 ` Robert Bridge 0 siblings, 0 replies; 20+ messages in thread From: Robert Bridge @ 2008-10-10 16:13 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-10 7:15 ` Fabian Groffen 2008-10-10 12:40 ` Diego 'Flameeyes' Pettenò @ 2008-10-10 15:21 ` Ryan Hill 1 sibling, 0 replies; 20+ messages in thread From: Ryan Hill @ 2008-10-10 15:21 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms 2008-10-09 18:11 [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms Fabian Groffen 2008-10-09 22:05 ` Marius Mauch @ 2008-10-10 8:56 ` Michael Haubenwallner 2008-10-10 12:56 ` Jeremy Olexa 2008-10-17 14:22 ` [gentoo-dev] " Michael Haubenwallner 3 siblings, 0 replies; 20+ messages in thread From: Michael Haubenwallner @ 2008-10-10 8:56 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms 2008-10-09 18:11 [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms Fabian Groffen 2008-10-09 22:05 ` Marius Mauch 2008-10-10 8:56 ` [gentoo-dev] " Michael Haubenwallner @ 2008-10-10 12:56 ` Jeremy Olexa 2008-10-13 5:16 ` [gentoo-dev] " Steve Long 2008-10-17 14:22 ` [gentoo-dev] " Michael Haubenwallner 3 siblings, 1 reply; 20+ messages in thread From: Jeremy Olexa @ 2008-10-10 12:56 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-10 12:56 ` Jeremy Olexa @ 2008-10-13 5:16 ` Steve Long 2008-10-13 14:27 ` Ciaran McCreesh 0 siblings, 1 reply; 20+ messages in thread From: Steve Long @ 2008-10-13 5:16 UTC (permalink / raw To: gentoo-dev 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-13 5:16 ` [gentoo-dev] " Steve Long @ 2008-10-13 14:27 ` Ciaran McCreesh 2008-10-13 17:59 ` Fabian Groffen 0 siblings, 1 reply; 20+ messages in thread From: Ciaran McCreesh @ 2008-10-13 14:27 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-13 14:27 ` Ciaran McCreesh @ 2008-10-13 17:59 ` Fabian Groffen 2008-10-14 7:48 ` Michael Haubenwallner 0 siblings, 1 reply; 20+ messages in thread From: Fabian Groffen @ 2008-10-13 17:59 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-13 17:59 ` Fabian Groffen @ 2008-10-14 7:48 ` Michael Haubenwallner 2008-10-15 10:20 ` [gentoo-dev] " Steve Long 0 siblings, 1 reply; 20+ messages in thread From: Michael Haubenwallner @ 2008-10-14 7:48 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-dev] Re: Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-14 7:48 ` Michael Haubenwallner @ 2008-10-15 10:20 ` Steve Long 0 siblings, 0 replies; 20+ messages in thread From: Steve Long @ 2008-10-15 10:20 UTC (permalink / raw To: gentoo-dev 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.) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms 2008-10-09 18:11 [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms Fabian Groffen ` (2 preceding siblings ...) 2008-10-10 12:56 ` Jeremy Olexa @ 2008-10-17 14:22 ` Michael Haubenwallner 2008-10-21 14:09 ` [gentoo-dev] " Tiziano Müller 3 siblings, 1 reply; 20+ messages in thread From: Michael Haubenwallner @ 2008-10-17 14:22 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-17 14:22 ` [gentoo-dev] " Michael Haubenwallner @ 2008-10-21 14:09 ` Tiziano Müller 2008-10-21 19:01 ` Fabian Groffen 0 siblings, 1 reply; 20+ messages in thread From: Tiziano Müller @ 2008-10-21 14:09 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms 2008-10-21 14:09 ` [gentoo-dev] " Tiziano Müller @ 2008-10-21 19:01 ` Fabian Groffen 0 siblings, 0 replies; 20+ messages in thread From: Fabian Groffen @ 2008-10-21 19:01 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2008-10-21 19:01 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-10-09 18:11 [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms Fabian Groffen 2008-10-09 22:05 ` Marius Mauch 2008-10-10 0:16 ` [gentoo-dev] " Duncan 2008-10-10 2:21 ` Marius Mauch 2008-10-10 7:15 ` Fabian Groffen 2008-10-10 12:40 ` Diego 'Flameeyes' Pettenò 2008-10-10 12:48 ` Fabian Groffen 2008-10-10 15:56 ` Marius Mauch 2008-10-10 16:13 ` Robert Bridge 2008-10-10 15:21 ` Ryan Hill 2008-10-10 8:56 ` [gentoo-dev] " Michael Haubenwallner 2008-10-10 12:56 ` Jeremy Olexa 2008-10-13 5:16 ` [gentoo-dev] " Steve Long 2008-10-13 14:27 ` Ciaran McCreesh 2008-10-13 17:59 ` Fabian Groffen 2008-10-14 7:48 ` Michael Haubenwallner 2008-10-15 10:20 ` [gentoo-dev] " Steve Long 2008-10-17 14:22 ` [gentoo-dev] " Michael Haubenwallner 2008-10-21 14:09 ` [gentoo-dev] " Tiziano Müller 2008-10-21 19:01 ` Fabian Groffen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox