| 1 |
Hi R0b0t1, |
| 2 |
|
| 3 |
R0b0t1 <r030t1@×××××.com> writes: |
| 4 |
|
| 5 |
> I don't want to just comment on naming, but: |
| 6 |
> |
| 7 |
> It might be more natural to go the other way. Split profiles off based |
| 8 |
> on version when breakage occurs, and otherwise do not reference a |
| 9 |
> specific version. |
| 10 |
> |
| 11 |
> Then, the name indicates the most recent kernel supported by the |
| 12 |
> profile. So remove the plus and (I think) shift all of the names |
| 13 |
> "forward." |
| 14 |
|
| 15 |
> So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name. |
| 16 |
> |
| 17 |
> This seems more natural but does change the semantics of the |
| 18 |
> name. Would that be a problem? |
| 19 |
|
| 20 |
Let's call this 'breakage-indicating scheme'. I have considered it, but |
| 21 |
finally I chose the original proposal: |
| 22 |
|
| 23 |
Consider one running kernel 3.8 with the newest profile, called |
| 24 |
'prefix/kernel-3.2+' in the original proposal and 'prefix' in the |
| 25 |
breakage-indicating scheme. When glibc decides to break <kernel-3.10, |
| 26 |
in the breakage-indicating scheme, you will have to change the profile |
| 27 |
to 'prefix/kernel-3.10-older'. |
| 28 |
|
| 29 |
Consider otherwise one running kernel 4.9, you will not not need to |
| 30 |
switch profile 'prefix/kernel-3.2+' in the original proposal, although |
| 31 |
'prefix/kernel-3.10+' will be a better profile. |
| 32 |
|
| 33 |
In either case, the original proposal does not force a profile switch |
| 34 |
when glibc breaks old kernel. Therefore I prefer it. |
| 35 |
|
| 36 |
> Is it expected people would want to use the profiles with |
| 37 |
> compatibility features on newer kernels? |
| 38 |
|
| 39 |
One use case is that: I want to bootstrap on my new and powerful server |
| 40 |
a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting |
| 41 |
Prefix to an aging RHEL 5. Bootstrapping a 'prefix/kernel-2.6.32-older' |
| 42 |
on kernel 4.9 feels awkward. |
| 43 |
|
| 44 |
But it is not about use cases, it is about logical consistancy: if we |
| 45 |
are not forbidden to run an old glibc on a new kernel, we should not |
| 46 |
indicate so in profile names. |
| 47 |
|
| 48 |
> This setup would prevent having to verify that old code works on new |
| 49 |
> systems, which is implied to be supported.by the + naming (again, not |
| 50 |
> sure if it matters). |
| 51 |
|
| 52 |
It is always supported to run an old glibc version on a new kernel, the |
| 53 |
linux kernel is ABI-backwords compatible. There is no need to verify |
| 54 |
that. Besides, by always using the most recent |
| 55 |
sys-kernel/linux-headers, we are guaranteed with the newest kernel API. |
| 56 |
|
| 57 |
Yours, |
| 58 |
Benda |
Archives