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 81B44138206 for ; Tue, 16 Jan 2018 05:23:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1AF0CE0880; Tue, 16 Jan 2018 05:23:04 +0000 (UTC) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (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 B631BE0858 for ; Tue, 16 Jan 2018 05:23:03 +0000 (UTC) Received: by mail-yw0-x244.google.com with SMTP id u21so6306003ywc.2 for ; Mon, 15 Jan 2018 21:23:03 -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=gnSPzMC1bKXF057hMY3R/0rVtY0Pd6jH3AVwWEe/Bf0=; b=cNxhnBtRCWQtLxdZbM0v5Yx0dz5Pp6RO+uUNVQFDVXiZqt6kjw3O7QjTaMaY4NycVs 1bJBTXlo7F0wj8BuNDNHEFwQUkDw2OaZrIzAq08w61wMWJ1Edot661MjiWGxtNH9zni9 oQ8FhOfvaKiH5Ir2filujCwT4uEsaqfOYCkE3VLMPdNXykVT7iNgmJESBePWkrL1GPAK ihKYj1kVWkkB/7AM56PiXvQv0HF+mJY8+yrlophkO1cYu6w+Vqqpk1VB/vY1xi9BsUI6 /xwjpAhG/q6RgvfVDkxWHUqZ+n07Jw9Ak82VQfhGwHyXeQ/qDb9d9XSBCy62cr40gX+x afOw== 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=gnSPzMC1bKXF057hMY3R/0rVtY0Pd6jH3AVwWEe/Bf0=; b=qdQHNQPzz7kTjJue6TzhRonSZTuHzGGTEFFG2nOHiLvnyoZMf4VKd8uiv5GMubPGgX DguQPXop8pb5ImmgVkWiQriGlIielaCQiytUoI0IRVpzFiSeDSroY2pBnG08SRUQk01o jmRT2ouYgszLUR1yV8O0ZOkjIzFpzEeEPBZmWads7gONmcuBLfuq3cJ5zjqHenosGP4D zeRjiVgcypYVAhS3AGqf2dqhlBUPTo4E+hKX/m77Y29rr1qNYHVAQ6HnVC3N5Wn+xw9n 6al12ojN6ytEM3rtN7R3qgWShV+1ir0EB18tYndAiP+SjfGrHpbkkZoKu2X6ENB8z4lv ry3w== X-Gm-Message-State: AKwxytcrACp30HoUjTe6/hgVsfdnJOzjdyWPGNyNJ0eJ04UrFOFdi9Uo Naz9X+x47aYcy+l8AULYcfep9z1pg60MEvUwjvCbPA== X-Google-Smtp-Source: ACJfBovWOgl4CpQbt9Kb69tqkbCWuXDyhGP/RqAu7ljr516P6A14mHzaabjBTyrQrWt98pqWUato7HjpiDjwDtZ11PE= X-Received: by 10.129.182.93 with SMTP id h29mr20880234ywk.348.1516080182453; Mon, 15 Jan 2018 21:23:02 -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:23:01 -0800 (PST) In-Reply-To: <878td3jynj.fsf@proton.d.airelinux.org> 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:23:01 -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: e2520f66-44d2-4ce8-936f-5eba98e71546 X-Archives-Hash: 7fea0891c086bd1b41a0c7f06d9eb7e6 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.: (Current.) *============================> *=====================> *==============> *=======> vs. (Usually seen.) *======* *======* *======* *=======> vs. (What it would actually mean for prefix.) *======*---------------------> *======*--------------> *======*-------> *=======> >> 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. Cheers, R0b0t1