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. > 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