Erm. On Mon, Jan 15, 2018 at 11:23 PM, R0b0t1 <r03...@gmail.com> wrote: > Hello, and my apologies for missing your message. > > On Fri, Jan 12, 2018 at 1:59 AM, Benda Xu <hero...@gentoo.org> wrote: >> Hi R0b0t1, >> >> R0b0t1 <r03...@gmail.com> 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 <kernel-3.10, >> 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.
