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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 06201158046 for ; Sat, 12 Oct 2024 15:10:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AF2C0E2A56; Sat, 12 Oct 2024 15:10:19 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7135AE2A52 for ; Sat, 12 Oct 2024 15:10:19 +0000 (UTC) From: Sam James To: Mitchell Dorrell Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14 In-Reply-To: (Mitchell Dorrell's message of "Sat, 12 Oct 2024 11:01:02 -0400") Organization: Gentoo References: Date: Sat, 12 Oct 2024 16:10:15 +0100 Message-ID: <87set1xsq0.fsf@gentoo.org> 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 7b820407-f41b-4f1a-a925-d48985a69ef9 X-Archives-Hash: 9f3125801fa6c287fa1af6d6fde37d10 Mitchell Dorrell writes: > How will the upgrade path look, from e.g. 3.16 to 3.17? What will the typ= ical Gentoo user experience be? What will the > experience be for a Python developer with a local overlay containing cust= om Python packages? It should be transparent because PYTHON_COMPAT will handle that as usual for a local repository. The upgrade thing will need testing just to make sure nothing odd happens though. > > I didn't like this idea at first, but I'm warming up to it. > > On Sat, Oct 12, 2024, 06:05 Micha=C5=82 G=C3=B3rny wr= ote: > > On Sat, 2024-10-12 at 11:59 +0200, Ulrich Mueller wrote: > > > > > > > On Sat, 12 Oct 2024, Micha=C5=82 G=C3=B3rny wrote: > >=20 > > > However, I think the cleanest way forward would be to stop slotting > > > CPython like this, and instead have a separate package for each vers= ion, > > > just like the vast majority of distributions do, i.e.: > >=20 > > > dev-lang/python3_N > >=20 > > That other distributions do it that way is not an argument because most > > other distributions don't have slots. > >=20 > > > This naturally means that only the specific version requested (e.g. = via > > > targets) would be installed, and no cross-slot autoupgrades would > > > happen. Ideally, I'd like to start doing that with Python 3.14 whose > > > first alpha is expected next week. Depending on how they handle > > > freethreading, we'd end up having the first or both of: > >=20 > > > dev-lang/python3_14 > > > dev-lang/python3_14t > >=20 > > IMHO this would abuse the package name for information that absolutely > > doesn't belong there. It belongs in PV or SLOT. > >=20 > > To me it seems that you try to work around a problem (greedy upgrade > > behaviour) that should really be solved in the package manager. > > In my opinion, it's the other way around. We have slots, that are a fit > solution for packages that are roughly compatible between every major > release, and we keep abusing them for every single thing we can bend > enough to make it fit. > > Greedy upgrade behavior makes sense when you have packages where :=3D > and :* operators are applicable. It doesn't make sense when every > single dependency is expected to specify an explicit slot. In fact, > when you are never supposed to depend on the package without specifying > a slot, why would you think slots are the right solution? > > In fact, the "freethreading" variation already implies that there could > be more than one "slot" per package version. > > It's as meaningless as having sqlite3 packaged as sqlite:3, or gtk that > is now randomly split between gtk+:2, gtk+:3 and gtk:4. > > --=20 > Best regards, > Micha=C5=82 G=C3=B3rny