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 49EA2158046 for ; Sat, 12 Oct 2024 13:52:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93F48E2A43; Sat, 12 Oct 2024 13:52:48 +0000 (UTC) Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (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 5B1A1E2A3B for ; Sat, 12 Oct 2024 13:52:48 +0000 (UTC) Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4XQlLQ5Vlpz9rxr for ; Sat, 12 Oct 2024 13:52:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1728741166; bh=owvMqKmJAIxty6m7rvg9hQ/9JTDss3lluckfbb2qHeY=; h=Date:From:To:Subject:In-Reply-To:References:From; b=s0gXRtsw9/ELt1kJkFa30AOtT20OfrmlaXBjINHU2ilddXu7DSEuz5+pa8+1hEHEV aUvJNeLTCyvfwKZ+TeYOL6KPulYrMPU3NvhUWia7mu+OGfxAMZmyVowoIaLQhZGX0e XixQOKGdHOwtjC5WzENs3DQ0Po4jDSPF9KFeVup8= X-Riseup-User-ID: DD20435DE6F282A14BF81E8464D57C0D3A473976D2A88A8978A8F87492BCD35B Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4XQlLQ3rWVzFwS5 for ; Sat, 12 Oct 2024 13:52:46 +0000 (UTC) Date: Sat, 12 Oct 2024 06:52:45 -0700 From: orbea To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14 Message-ID: <20241012065245.2944d365@Akita> In-Reply-To: References: 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: 01452bd6-3c95-4a4e-977b-63038007cbb2 X-Archives-Hash: 68945f644234abad25f6e091e4438a9e On Sat, 12 Oct 2024 10:12:56 +0200 Micha=C5=82 G=C3=B3rny wrote: > Hello, >=20 > Historically, all versions of CPython were slotted in a single > package, i.e.: >=20 > dev-lang/python:3.N >=20 > This approach has been causing a major annoyance for users -- due to > Portage "greedy" upgrade behavior, any time a new Python version was > keyworded, Portage insisted on installing it, even though user's > selected targets did not request the specific version. The > potentially worst consequence of that would be random user scripts > stopping to work, as they suddenly start using new Python, while all > their dependencies are still installed per PYTHON_TARGETS. >=20 > Upstream has recently added freethreading support to CPython. Since > this support is not ABI compatible with the regular build, we need to > introduce a separate target for it, and to package it separately. > In the planned patchset, I've already put it as a separate package > (dev- lang/python-freethreading), because otherwise Portage would > insist on upgrading to it! >=20 > However, I think the cleanest way forward would be to stop slotting > CPython like this, and instead have a separate package for each > version, just like the vast majority of distributions do, i.e.: >=20 > dev-lang/python3_N >=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 > (Alternatives: python-3_14, python-freethreading-3_14? Though I think > following PYTHON_TARGETS is cleaner here.) >=20 > As a side notice, the existing versions would probably remain as-is > until removal, since there's really no gain in splitting them, given > we'd have to retain compatibility with existing depstrings. >=20 > Comments? >=20 Would you be willing to carry the LibreSSL patches in tree if you do this? Its already a serious chore keeping the python ebuilds in sync with ::gentoo and if you start to double the versions that will only be more ridiculous.