Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
Hi, R0b0t1 writes: > I have seen similar choices made before, but this is the first time I > have seen a good case for the choice you selected. E.g.: > > (Current.) > *> >*=> > *==> > *===> > > vs. > > (Usually seen.) > *==* >*==* > *==* > *===> > > vs. > > (What it would actually mean for prefix.) > *==*-> >*==*--> > *==*---> > *===> > Nice assci art! Indeed the 3rd case is what I want to express. It is a big challenge though to express it within 20 characters in the profile name. So I chose the first one as approximation. >>> This setup would prevent having to verify that old code works on new >>> systems, which is implied to be supported.by the + naming (again, not >>> sure if it matters). >> >> It is always supported to run an old glibc version on a new kernel, the >> linux kernel is ABI-backwords compatible. There is no need to verify >> that. Besides, by always using the most recent >> sys-kernel/linux-headers, we are guaranteed with the newest kernel API. >> > > It might be for the foreseeable future, but that might change. The > comment was more about the features exposed to glibc and the programs > installed via portage. It seems to me as the kernel and userland > progress, The older profile would require constant adjustment. Perhaps > I am not explaining it well, my apologies. That is the norm for maintaining profiles. We are actually doing constant adjustment to profiles until they are deprecated and removed. So don't worry. We have enough time to react if that changes. Yours, Benda
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
Erm. On Mon, Jan 15, 2018 at 11:23 PM, R0b0t1 wrote: > Hello, and my apologies for missing your message. > > On Fri, Jan 12, 2018 at 1:59 AM, Benda Xu wrote: >> Hi R0b0t1, >> >> R0b0t1 writes: >> >>> I don't want to just comment on naming, but: >>> >>> It might be more natural to go the other way. Split profiles off based >>> on version when breakage occurs, and otherwise do not reference a >>> specific version. >>> >>> Then, the name indicates the most recent kernel supported by the >>> profile. So remove the plus and (I think) shift all of the names >>> "forward." >> >>> So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name. >>> >>> This seems more natural but does change the semantics of the >>> name. Would that be a problem? >> >> Let's call this 'breakage-indicating scheme'. I have considered it, but >> finally I chose the original proposal: >> >> Consider one running kernel 3.8 with the newest profile, called >> 'prefix/kernel-3.2+' in the original proposal and 'prefix' in the >> breakage-indicating scheme. When glibc decides to break > in the breakage-indicating scheme, you will have to change the profile >> to 'prefix/kernel-3.10-older'. >> >> Consider otherwise one running kernel 4.9, you will not not need to >> switch profile 'prefix/kernel-3.2+' in the original proposal, although >> 'prefix/kernel-3.10+' will be a better profile. >> >> In either case, the original proposal does not force a profile switch >> when glibc breaks old kernel. Therefore I prefer it. >> > > This makes sense. While I agree that minimizing breakage is a good > idea, I am not sure it should be favored over all alternatives. > >>> Is it expected people would want to use the profiles with >>> compatibility features on newer kernels? >> >> One use case is that: I want to bootstrap on my new and powerful server >> a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting >> Prefix to an aging RHEL 5. Bootstrapping a 'prefix/kernel-2.6.32-older' >> on kernel 4.9 feels awkward. >> >> But it is not about use cases, it is about logical consistancy: if we >> are not forbidden to run an old glibc on a new kernel, we should not >> indicate so in profile names. >> > > I have seen similar choices made before, but this is the first time I > have seen a good case for the choice you selected. E.g.: > (Lines up in a monospaced font.) >>> This setup would prevent having to verify that old code works on new >>> systems, which is implied to be supported.by the + naming (again, not >>> sure if it matters). >> >> It is always supported to run an old glibc version on a new kernel, the >> linux kernel is ABI-backwords compatible. There is no need to verify >> that. Besides, by always using the most recent >> sys-kernel/linux-headers, we are guaranteed with the newest kernel API. >> > > It might be for the foreseeable future, but that might change. The > comment was more about the features exposed to glibc and the programs > installed via portage. It seems to me as the kernel and userland > progress, the older profile. Perhaps I am not explaining it well, my > apologies. > The older profile would require constant adjustment.
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
Hello, and my apologies for missing your message. On Fri, Jan 12, 2018 at 1:59 AM, Benda Xu wrote: > Hi R0b0t1, > > R0b0t1 writes: > >> I don't want to just comment on naming, but: >> >> It might be more natural to go the other way. Split profiles off based >> on version when breakage occurs, and otherwise do not reference a >> specific version. >> >> Then, the name indicates the most recent kernel supported by the >> profile. So remove the plus and (I think) shift all of the names >> "forward." > >> So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name. >> >> This seems more natural but does change the semantics of the >> name. Would that be a problem? > > Let's call this 'breakage-indicating scheme'. I have considered it, but > finally I chose the original proposal: > > Consider one running kernel 3.8 with the newest profile, called > 'prefix/kernel-3.2+' in the original proposal and 'prefix' in the > breakage-indicating scheme. When glibc decides to break in the breakage-indicating scheme, you will have to change the profile > to 'prefix/kernel-3.10-older'. > > Consider otherwise one running kernel 4.9, you will not not need to > switch profile 'prefix/kernel-3.2+' in the original proposal, although > 'prefix/kernel-3.10+' will be a better profile. > > In either case, the original proposal does not force a profile switch > when glibc breaks old kernel. Therefore I prefer it. > This makes sense. While I agree that minimizing breakage is a good idea, I am not sure it should be favored over all alternatives. >> Is it expected people would want to use the profiles with >> compatibility features on newer kernels? > > One use case is that: I want to bootstrap on my new and powerful server > a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting > Prefix to an aging RHEL 5. Bootstrapping a 'prefix/kernel-2.6.32-older' > on kernel 4.9 feels awkward. > > But it is not about use cases, it is about logical consistancy: if we > are not forbidden to run an old glibc on a new kernel, we should not > indicate so in profile names. > I have seen similar choices made before, but this is the first time I have seen a good case for the choice you selected. E.g.: (Current.) *> *=> *==> *===> vs. (Usually seen.) *==* *==* *==* *===> vs. (What it would actually mean for prefix.) *==*-> *==*--> *==*---> *===> >> This setup would prevent having to verify that old code works on new >> systems, which is implied to be supported.by the + naming (again, not >> sure if it matters). > > It is always supported to run an old glibc version on a new kernel, the > linux kernel is ABI-backwords compatible. There is no need to verify > that. Besides, by always using the most recent > sys-kernel/linux-headers, we are guaranteed with the newest kernel API. > It might be for the foreseeable future, but that might change. The comment was more about the features exposed to glibc and the programs installed via portage. It seems to me as the kernel and userland progress, the older profile. Perhaps I am not explaining it well, my apologies. Cheers, R0b0t1
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
Hi Patrice, Patrice Clement writes: > Thanks for the work. > > Could you also consider adding a Prefix profile compatible with > FreeBSD? We have supported BSD before. But at the moment, no one on the Prefix team have access to BSD hosts. Historically, fauli has developped Prefix on FreeBSD 8: https://wiki.gentoo.org/wiki/Project:Prefix But now the port is outdated and removed in Jan 2017: https://archives.gentoo.org/gentoo-alt/message/cf3af6ba4d2c56ea6c2451435b33eddf You are more than welcomed to revive Prefix on FreeBSD. Cheers, Benda
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
Hi Benda Monday 08 Jan 2018 15:38:49, Benda Xu wrote : > Hi, > > I would like to introduce some 17.0 profile for Prefix. It also > introduces separate profiles to support different ranges of linux > kernels. > > | name | linux| glibc | > |--+--+---| > | beyond-kernel-2.6.16 | [2.6.16, 2.6.32) | <2.20 | > | beyond-kernel-2.6.32 | [2.6.32, 3.2)| <2.24 | > | beyond-kernel-3.2| [3.2, latest)| latest| > > Attached is the patch. Thoughts and comments? > > Yours, > Benda > --- > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi | 1 + > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent | 2 ++ > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi | 1 + > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent | 2 ++ > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi | 1 + > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent| 2 ++ > profiles/default/linux/amd64/17.0/no-multilib/prefix/parent | 1 + > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi| 1 + > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent | 2 ++ > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi| 1 + > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent | 2 ++ > profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi | 1 + > profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent | 2 ++ > profiles/default/linux/x86/17.0/prefix/parent | 1 + > profiles/profiles.desc | 6 > ++ > 15 files changed, 26 insertions(+) > create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi > create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent > create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi > create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent > create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi > create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent > create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/parent > create mode 100644 > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi > create mode 100644 > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent > create mode 100644 > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi > create mode 100644 > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent > create mode 100644 > profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi > create mode 100644 > profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent > create mode 100644 profiles/default/linux/x86/17.0/prefix/parent > > diff --git > a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi > > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi > new file mode 100644 > index ..7ed6ff82de6b > --- /dev/null > +++ > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi > @@ -0,0 +1 @@ > +5 > diff --git > a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent > > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent > new file mode 100644 > index ..6a349d3df196 > --- /dev/null > +++ > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent > @@ -0,0 +1,2 @@ > +.. > +../../../../../../../features/prefix/standalone/beyond-kernel-2.6.16 > diff --git > a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi > > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi > new file mode 100644 > index ..7ed6ff82de6b > --- /dev/null > +++ > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi > @@ -0,0 +1 @@ > +5 > diff --git > a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent > > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent > new file mode 100644 > index ..f14f9dcf77ee > --- /dev/null > +++ > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent > @@ -0,0 +1,2 @@ > +.. > +../../../../../../../features/prefix/standalone/beyond-kernel-2.6.32 > diff --git > a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi > new file mode 100644 > index ..7ed6ff82de6b > --- /dev/null > +++ > b/pr
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
Hi R0b0t1, R0b0t1 writes: > I don't want to just comment on naming, but: > > It might be more natural to go the other way. Split profiles off based > on version when breakage occurs, and otherwise do not reference a > specific version. > > Then, the name indicates the most recent kernel supported by the > profile. So remove the plus and (I think) shift all of the names > "forward." > So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name. > > This seems more natural but does change the semantics of the > name. Would that be a problem? Let's call this 'breakage-indicating scheme'. I have considered it, but finally I chose the original proposal: Consider one running kernel 3.8 with the newest profile, called 'prefix/kernel-3.2+' in the original proposal and 'prefix' in the breakage-indicating scheme. When glibc decides to break Is it expected people would want to use the profiles with > compatibility features on newer kernels? One use case is that: I want to bootstrap on my new and powerful server a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting Prefix to an aging RHEL 5. Bootstrapping a 'prefix/kernel-2.6.32-older' on kernel 4.9 feels awkward. But it is not about use cases, it is about logical consistancy: if we are not forbidden to run an old glibc on a new kernel, we should not indicate so in profile names. > This setup would prevent having to verify that old code works on new > systems, which is implied to be supported.by the + naming (again, not > sure if it matters). It is always supported to run an old glibc version on a new kernel, the linux kernel is ABI-backwords compatible. There is no need to verify that. Besides, by always using the most recent sys-kernel/linux-headers, we are guaranteed with the newest kernel API. Yours, Benda
[gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On Wednesday, January 10, 2018, Benda Xu wrote: > Hi MJ, > > "M. J. Everitt" writes: > >> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the >> different between 2.6.16+ and 2.6.32+ .. should this potentially be >> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me, >> and more confusing to others > > 2.6.16+ means that it can be used in any cases when the kernel is newer > than 2.6.16. For example, you can use it on linux-4.14, just with > unnecessary backward compatibility code. > > Besides, with the newest profile, kernel-3.2+, the ending kernel version > is not known. We will have to rename it when glibc jumps if the profile > is named with a version range. > I don't want to just comment on naming, but: It might be more natural to go the other way. Split profiles off based on version when breakage occurs, and otherwise do not reference a specific version. Then, the name indicates the most recent kernel supported by the profile. So remove the plus and (I think) shift all of the names "forward." So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name. This seems more natural but does change the semantics of the name. Would that be a problem? Is it expected people would want to use the profiles with compatibility features on newer kernels? This setup would prevent having to verify that old code works on new systems, which is implied to be supported.by the + naming (again, not sure if it matters). Cheers, R0b0t1
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On 11/01/18 03:18, Benda Xu wrote: > Hi MJ, > > "M. J. Everitt" writes: > >> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the >> different between 2.6.16+ and 2.6.32+ .. should this potentially be >> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me, >> and more confusing to others > 2.6.16+ means that it can be used in any cases when the kernel is newer > than 2.6.16. For example, you can use it on linux-4.14, just with > unnecessary backward compatibility code. > > Besides, with the newest profile, kernel-3.2+, the ending kernel version > is not known. We will have to rename it when glibc jumps if the profile > is named with a version range. > > > Hope this addresses your concern. > > Cheers, > Benda Thanks, that does make sense! MJE signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
Hi MJ, "M. J. Everitt" writes: > Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the > different between 2.6.16+ and 2.6.32+ .. should this potentially be > 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me, > and more confusing to others 2.6.16+ means that it can be used in any cases when the kernel is newer than 2.6.16. For example, you can use it on linux-4.14, just with unnecessary backward compatibility code. Besides, with the newest profile, kernel-3.2+, the ending kernel version is not known. We will have to rename it when glibc jumps if the profile is named with a version range. Hope this addresses your concern. Cheers, Benda signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On 10/01/18 14:00, kuzetsa wrote: > On 01/09/2018 08:21 AM, Aaron Bauman wrote: >> On January 8, 2018 9:39:47 PM EST, Benda Xu wrote: >>> Hi kuzetsa, >>> >>> kuzetsa writes: >>> The term "beyond" feels wrong & confusing. (Not sure what to replace it with though) >>> How about this? >>> >>> default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ >>> default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+ >>> default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+ >>> >>> Yours, >>> Benda >> I like this as it is shorter and makes the version ranges more clear. Lgtm. >> >> -Aaron > Yes. Using a plus looks nicer / cleaner to me too. > Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the different between 2.6.16+ and 2.6.32+ .. should this potentially be 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me, and more confusing to others MJE signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On 01/09/2018 08:21 AM, Aaron Bauman wrote: > > On January 8, 2018 9:39:47 PM EST, Benda Xu wrote: >> Hi kuzetsa, >> >> kuzetsa writes: >> >>> The term "beyond" feels wrong & confusing. >>> (Not sure what to replace it with though) >> How about this? >> >> default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ >> default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+ >> default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+ >> >> Yours, >> Benda > I like this as it is shorter and makes the version ranges more clear. Lgtm. > > -Aaron Yes. Using a plus looks nicer / cleaner to me too. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On January 8, 2018 9:39:47 PM EST, Benda Xu wrote: >Hi kuzetsa, > >kuzetsa writes: > >> The term "beyond" feels wrong & confusing. >> (Not sure what to replace it with though) > >How about this? > > default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ > default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+ > default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+ > >Yours, >Benda I like this as it is shorter and makes the version ranges more clear. Lgtm. -Aaron -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
Hi Aaron, Aaron Bauman writes: > I am not too familair with prefix other than the purpose of it (e.g. I > have never built it), but is there a better naming standard for the > profiles? I understand the need to distinguish between the kernel and > glibc versions. > Is there a standard I am missing for profile names? From PMS, there is no words on profile naming. But I think adopting naming of category [A-Za-z0-9+_.-] will not be too wrong: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-170003.1.1 > Could there be a wiki explaining a prefix profile versioning that > correlates to the glibc and kernel versions? Or is the intent to keep > it simple and easily identifiable from within the PM? A wiki page would be a good idea for detailed explanations. > Not a big deal, but just my thoughts. Thanks for your work on prefix > and I am sure many will benefit from the new profiles :) Thanks for inputs! Yours, Benda signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
Hi kuzetsa, kuzetsa writes: > The term "beyond" feels wrong & confusing. > (Not sure what to replace it with though) How about this? default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+ default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+ Yours, Benda signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On Monday, January 8, 2018 1:38:49 AM EST Benda Xu wrote: > Hi, > > I would like to introduce some 17.0 profile for Prefix. It also > introduces separate profiles to support different ranges of linux > kernels. > > | name | linux| glibc | > | > |--+--+---| > | > | beyond-kernel-2.6.16 | [2.6.16, 2.6.32) | <2.20 | > | beyond-kernel-2.6.32 | [2.6.32, 3.2)| <2.24 | > | beyond-kernel-3.2| [3.2, latest)| latest| > > Attached is the patch. Thoughts and comments? > > Yours, > Benda > --- > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi | 1 + > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent | 2 ++ > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi | 1 + > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent | 2 ++ > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi | 1 + > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent| 2 ++ > profiles/default/linux/amd64/17.0/no-multilib/prefix/parent | 1 + > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi| 1 + > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent | 2 ++ > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi| 1 + > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent | 2 ++ > profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi | 1 + > profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent | 2 ++ > profiles/default/linux/x86/17.0/prefix/parent | 1 + > profiles/profiles.desc | 6 > ++ 15 files changed, 26 insertions(+) > create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/e > api create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/p > arent create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/e > api create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/p > arent create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi > create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/pare > nt create mode 100644 > profiles/default/linux/amd64/17.0/no-multilib/prefix/parent create mode > 100644 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi > create mode 100644 > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent create > mode 100644 > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi create > mode 100644 > profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent create > mode 100644 profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi > create mode 100644 > profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent create mode > 100644 profiles/default/linux/x86/17.0/prefix/parent > > diff --git > a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16 > /eapi > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16 > /eapi new file mode 100644 > index ..7ed6ff82de6b > --- /dev/null > +++ > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16 > /eapi @@ -0,0 +1 @@ > +5 > diff --git > a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16 > /parent > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16 > /parent new file mode 100644 > index ..6a349d3df196 > --- /dev/null > +++ > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16 > /parent @@ -0,0 +1,2 @@ > +.. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On 01/08/2018 01:38 AM, Benda Xu wrote: > Hi, > > I would like to introduce some 17.0 profile for Prefix. It also > introduces separate profiles to support different ranges of linux > kernels. > > | name | linux| glibc | > |--+--+---| > | beyond-kernel-2.6.16 | [2.6.16, 2.6.32) | <2.20 | > | beyond-kernel-2.6.32 | [2.6.32, 3.2)| <2.24 | > | beyond-kernel-3.2| [3.2, latest)| latest| > > Attached is the patch. Thoughts and comments? > > Yours, > Benda > --- > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi | 1 + > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent | 2 ++ [...] Not sure what else is changed / added. The term "beyond" feels wrong & confusing. (Not sure what to replace it with though) signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
Hi, I would like to introduce some 17.0 profile for Prefix. It also introduces separate profiles to support different ranges of linux kernels. | name | linux| glibc | |--+--+---| | beyond-kernel-2.6.16 | [2.6.16, 2.6.32) | <2.20 | | beyond-kernel-2.6.32 | [2.6.32, 3.2)| <2.24 | | beyond-kernel-3.2| [3.2, latest)| latest| Attached is the patch. Thoughts and comments? Yours, Benda --- .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi | 1 + .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent | 2 ++ .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi | 1 + .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent | 2 ++ .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi | 1 + .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent| 2 ++ profiles/default/linux/amd64/17.0/no-multilib/prefix/parent | 1 + profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi| 1 + profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent | 2 ++ profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi| 1 + profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent | 2 ++ profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi | 1 + profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent | 2 ++ profiles/default/linux/x86/17.0/prefix/parent | 1 + profiles/profiles.desc | 6 ++ 15 files changed, 26 insertions(+) create mode 100644 profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi create mode 100644 profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent create mode 100644 profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi create mode 100644 profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent create mode 100644 profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi create mode 100644 profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent create mode 100644 profiles/default/linux/amd64/17.0/no-multilib/prefix/parent create mode 100644 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi create mode 100644 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent create mode 100644 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi create mode 100644 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent create mode 100644 profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi create mode 100644 profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent create mode 100644 profiles/default/linux/x86/17.0/prefix/parent diff --git a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi new file mode 100644 index ..7ed6ff82de6b --- /dev/null +++ b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi @@ -0,0 +1 @@ +5 diff --git a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent new file mode 100644 index ..6a349d3df196 --- /dev/null +++ b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent @@ -0,0 +1,2 @@ +.. +../../../../../../../features/prefix/standalone/beyond-kernel-2.6.16 diff --git a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi new file mode 100644 index ..7ed6ff82de6b --- /dev/null +++ b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi @@ -0,0 +1 @@ +5 diff --git a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent new file mode 100644 index ..f14f9dcf77ee --- /dev/null +++ b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent @@ -0,0 +1,2 @@ +.. +../../../../../../../features/prefix/standalone/beyond-kernel-2.6.32 diff --git a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi new file mode 100644 index ..7ed6ff82de6b --- /dev/null +++ b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi @@ -0,0 +1 @@ +5 diff --git a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent new file mode 100644 index