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

[Benda Xu <heroxbd@gentoo.org>]

Hi R0b0t1,

R0b0t1 <r030t1@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