Hi, R0b0t1 <r03...@gmail.com> writes:
> 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.) > *======*---------------------> > *======*--------------> > *======*-------> > *=======> > Nice assci art! Indeed the 3rd case is what I want to express. It is a big challenge though to express it within 20 characters in the profile name. So I chose the first one as approximation. >>> 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 would require constant adjustment. Perhaps > I am not explaining it well, my apologies. That is the norm for maintaining profiles. We are actually doing constant adjustment to profiles until they are deprecated and removed. So don't worry. We have enough time to react if that changes. Yours, Benda
