| 1 |
Erm. |
| 2 |
|
| 3 |
On Mon, Jan 15, 2018 at 11:23 PM, R0b0t1 <r030t1@×××××.com> wrote: |
| 4 |
> Hello, and my apologies for missing your message. |
| 5 |
> |
| 6 |
> On Fri, Jan 12, 2018 at 1:59 AM, Benda Xu <heroxbd@g.o> wrote: |
| 7 |
>> Hi R0b0t1, |
| 8 |
>> |
| 9 |
>> R0b0t1 <r030t1@×××××.com> writes: |
| 10 |
>> |
| 11 |
>>> I don't want to just comment on naming, but: |
| 12 |
>>> |
| 13 |
>>> It might be more natural to go the other way. Split profiles off based |
| 14 |
>>> on version when breakage occurs, and otherwise do not reference a |
| 15 |
>>> specific version. |
| 16 |
>>> |
| 17 |
>>> Then, the name indicates the most recent kernel supported by the |
| 18 |
>>> profile. So remove the plus and (I think) shift all of the names |
| 19 |
>>> "forward." |
| 20 |
>> |
| 21 |
>>> So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name. |
| 22 |
>>> |
| 23 |
>>> This seems more natural but does change the semantics of the |
| 24 |
>>> name. Would that be a problem? |
| 25 |
>> |
| 26 |
>> Let's call this 'breakage-indicating scheme'. I have considered it, but |
| 27 |
>> finally I chose the original proposal: |
| 28 |
>> |
| 29 |
>> Consider one running kernel 3.8 with the newest profile, called |
| 30 |
>> 'prefix/kernel-3.2+' in the original proposal and 'prefix' in the |
| 31 |
>> breakage-indicating scheme. When glibc decides to break <kernel-3.10, |
| 32 |
>> in the breakage-indicating scheme, you will have to change the profile |
| 33 |
>> to 'prefix/kernel-3.10-older'. |
| 34 |
>> |
| 35 |
>> Consider otherwise one running kernel 4.9, you will not not need to |
| 36 |
>> switch profile 'prefix/kernel-3.2+' in the original proposal, although |
| 37 |
>> 'prefix/kernel-3.10+' will be a better profile. |
| 38 |
>> |
| 39 |
>> In either case, the original proposal does not force a profile switch |
| 40 |
>> when glibc breaks old kernel. Therefore I prefer it. |
| 41 |
>> |
| 42 |
> |
| 43 |
> This makes sense. While I agree that minimizing breakage is a good |
| 44 |
> idea, I am not sure it should be favored over all alternatives. |
| 45 |
> |
| 46 |
>>> Is it expected people would want to use the profiles with |
| 47 |
>>> compatibility features on newer kernels? |
| 48 |
>> |
| 49 |
>> One use case is that: I want to bootstrap on my new and powerful server |
| 50 |
>> a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting |
| 51 |
>> Prefix to an aging RHEL 5. Bootstrapping a 'prefix/kernel-2.6.32-older' |
| 52 |
>> on kernel 4.9 feels awkward. |
| 53 |
>> |
| 54 |
>> But it is not about use cases, it is about logical consistancy: if we |
| 55 |
>> are not forbidden to run an old glibc on a new kernel, we should not |
| 56 |
>> indicate so in profile names. |
| 57 |
>> |
| 58 |
> |
| 59 |
> I have seen similar choices made before, but this is the first time I |
| 60 |
> have seen a good case for the choice you selected. E.g.: |
| 61 |
> |
| 62 |
|
| 63 |
(Lines up in a monospaced font.) |
| 64 |
|
| 65 |
>>> This setup would prevent having to verify that old code works on new |
| 66 |
>>> systems, which is implied to be supported.by the + naming (again, not |
| 67 |
>>> sure if it matters). |
| 68 |
>> |
| 69 |
>> It is always supported to run an old glibc version on a new kernel, the |
| 70 |
>> linux kernel is ABI-backwords compatible. There is no need to verify |
| 71 |
>> that. Besides, by always using the most recent |
| 72 |
>> sys-kernel/linux-headers, we are guaranteed with the newest kernel API. |
| 73 |
>> |
| 74 |
> |
| 75 |
> It might be for the foreseeable future, but that might change. The |
| 76 |
> comment was more about the features exposed to glibc and the programs |
| 77 |
> installed via portage. It seems to me as the kernel and userland |
| 78 |
> progress, the older profile. Perhaps I am not explaining it well, my |
| 79 |
> apologies. |
| 80 |
> |
| 81 |
|
| 82 |
The older profile would require constant adjustment. |
Archives