From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 1BA0B1381F1 for ; Fri, 12 Jan 2018 07:59:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 78FB9E0923; Fri, 12 Jan 2018 07:59:17 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2554AE08E2 for ; Fri, 12 Jan 2018 07:59:16 +0000 (UTC) Received: from proton (v150-95-148-30.a08d.g.tyo1.static.cnode.io [150.95.148.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: heroxbd) by smtp.gentoo.org (Postfix) with ESMTPSA id B9202335C3C for ; Fri, 12 Jan 2018 07:59:15 +0000 (UTC) From: Benda Xu To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles. References: <87incciwrn.fsf@proton.d.airelinux.org> <878td721sc.fsf@gentoo.org> <93D4A852-09FD-4690-8553-EBA5FEECDED1@gentoo.org> <943342a4-1d72-7da3-c985-ac3ffde2bfed@gmail.com> <197837c5-a1f4-2c2c-5027-a98af1494df2@iee.org> <87h8rtkrqr.fsf@proton.d.airelinux.org> Date: Fri, 12 Jan 2018 16:59:12 +0900 In-Reply-To: (R0b0t1's message of "Thu, 11 Jan 2018 08:15:23 -0600") Message-ID: <878td3jynj.fsf@proton.d.airelinux.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain X-Archives-Salt: 39642c8c-4a65-47f4-b532-52ad58242ecb X-Archives-Hash: cb11c621ee13696e9e51d4a3a83c9edb Hi R0b0t1, R0b0t1 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 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