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 DCCA8138206 for ; Tue, 16 Jan 2018 05:25:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1B89FE088C; Tue, 16 Jan 2018 05:24:58 +0000 (UTC) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 BE654E0876 for ; Tue, 16 Jan 2018 05:24:57 +0000 (UTC) Received: by mail-yw0-x235.google.com with SMTP id b129so6298470ywa.8 for ; Mon, 15 Jan 2018 21:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=72/CnDFa8y/X0wij6B0QvGTvAJ15MvQTxsFEMtPAiZQ=; b=l+kpyZODXBmu1ggjHkJ+haGomd8QPWwDPo8kUdtFtiaoUKqNggYlWGv8NQAP+4oEPn A795Ns98janAj8U8RukNUR1QaEzC/Ta3pdsp31xtS9OPjhJFw1mZGd2L+GjwtcN+0dyW D0ZTKwPbnf7/LG9dMgzC/wSxVDP26e1Z2lQG51VhtuMRsrVEcH0sAJ1NlETmut047vKn ctHFAhj/r1YQVqJLRIAaVQ/R78U1g9pK44Oy/jzmaLL+K5NZq0GKYZLpPbsZdfTqoiLH o/IZWopnlQSh/PaCLA0bF931ST4tmKawvZvHe5TADKgQgXne2h0uXWTns7847OW+mNth 0GXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=72/CnDFa8y/X0wij6B0QvGTvAJ15MvQTxsFEMtPAiZQ=; b=GhneZn3uEAYfFQprIHKK10mLzEWPizfY3s11B+t2EvsJ3i3FClgTQMZKuxij6NIbkL FPhBJqBT1csE6TS8iLLf8mycudz/ucAaJsxjtP61GEeizTf9H/YXV5H67v5bV5fMRfkg vHuZJF0eo/ESaUbf+FyOKxtET36jqKZNZY5qEbK2Qeb156qj2LU8904YFNUA5pPhHEsw Vm9Wm0x/4x5O/wMiwXwVmz6ufHaCpU/QpzAlBemCEqeo+Qio/lZk7JEVAFxNYhOmQBkl KuAM+ugCn5OLaHg3t2bks+XOYJV13m7Woi8VUiaE1xzVIeh1Z9dhdJfcFpEGpTZfaXH+ UwKA== X-Gm-Message-State: AKGB3mKS/QlLiaTHoIHB2eUXhGXnD9kvzo3qTDxPe9TxQp8YZyE5/dKf DfDPixj2rlYdhd253EpK1StDCUtp3bvcI+ngws8= X-Google-Smtp-Source: ACJfBosdFBAgwk+Q1q/O3PE565QKuXbMkDEUXz245XFeIM6CsRR+zbQyBD9PSDv/iMrN8jXUoYA2+3DFWPOBFzZhzXc= X-Received: by 10.129.114.215 with SMTP id n206mr26085815ywc.427.1516080296562; Mon, 15 Jan 2018 21:24:56 -0800 (PST) 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 Received: by 10.129.84.85 with HTTP; Mon, 15 Jan 2018 21:24:56 -0800 (PST) In-Reply-To: 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> <878td3jynj.fsf@proton.d.airelinux.org> From: R0b0t1 Date: Mon, 15 Jan 2018 23:24:56 -0600 Message-ID: Subject: Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles. To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 0a428889-a71e-4405-9017-9dc598c0d1eb X-Archives-Hash: c99ed131cbb21d807a352bac5254ff96 Erm. On Mon, Jan 15, 2018 at 11:23 PM, R0b0t1 wrote: > Hello, and my apologies for missing your message. > > On Fri, Jan 12, 2018 at 1:59 AM, Benda Xu wrote: >> 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 > 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. >> > > This makes sense. While I agree that minimizing breakage is a good > idea, I am not sure it should be favored over all alternatives. > >>> 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. >> > > 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.: > (Lines up in a monospaced font.) >>> 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. Perhaps I am not explaining it well, my > apologies. > The older profile would require constant adjustment.