Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[R0b0t1]

Hello, and my apologies for missing your message.

On Fri, Jan 12, 2018 at 1:59 AM, Benda Xu <heroxbd@g.o> wrote:
> Hi R0b0t1,
>
> R0b0t1 <r030t1@×××××.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.:

(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