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 (4096 bits) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id BED8F158046 for ; Sat, 12 Oct 2024 23:02:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93354E08F3; Sat, 12 Oct 2024 23:02:25 +0000 (UTC) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 D986BE08E8 for ; Sat, 12 Oct 2024 23:02:23 +0000 (UTC) Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-71e30e56ce5so1787797b3a.1 for ; Sat, 12 Oct 2024 16:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=psc.edu; s=google; t=1728774142; x=1729378942; darn=lists.gentoo.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fOJe3cVUliXSuc5tz4XUcQTclN2y1aX+OB/bWzhJxq8=; b=aIknfX28G8kbiJu3fGEtEcV0Xes5ZAqstijSsNM3IQqLRL5s5KJwOszfQK4jUeDMRa 4jGn1O9Ul8JoDgbmK6jNWomvBF1qLAVx/3Qh81qQbzFPt8j0fF5a+CJKugdMWt+1rjog lV1qudyFa4z6XgoLzw3v1dVAKCQ8IAH68Q4qA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728774142; x=1729378942; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fOJe3cVUliXSuc5tz4XUcQTclN2y1aX+OB/bWzhJxq8=; b=NWQmcX25EnbAussgqOLYakC9zj7SzGhldChGqJRX/obvxkuQl+H/5CEz2DJnvO+p7u g2Osr9Q3AmauQCuSrBg6OgEtM9x8AKUtGKxCvG/IFZPtinEta3qsZdtawYm/6HskHvoC H4LmaincaJyGeDOnjKyhAyJgQKhynKJvWTDUD/HBDHY/jPG632s4H/qhjwUl7Ykyyc+G zcUC7O5bmvNwYaGD+rY264TSMOYCOt+KBsNxlE6I66Kjk+yRvfaJ/uFHPQPyt6RJIqvO eaUb2CRRNQ6Kn3b9YVe/rSOoPOXXkO2WQu20DWkeDjXSWtFT7Y0vQGkP9mHsNsLJSQG5 XR2w== X-Gm-Message-State: AOJu0YyyS+loSCn/gRmWrNViOhIOc2g+Z9atBpCAcnuVmQLHf0lESSXb p05hyqrmnrig1F/LOVgtKSM9jR4VCFCNZNo8Ts0umiWptzN4n9tUoVeH3nrhhVKOY5Nm3VvvcoK iZrY7gWAuUfJzVe1Nsj3qdyUq1NYjmViO71Pmlb19JkUhRQhS X-Google-Smtp-Source: AGHT+IFvnSBJt+IDVJ2xkozTIBMSMHNA0Z62hryMfxX0I6X3wiTzvVQ3OKg4W9bO0vrnXYb2g+03wXs2blcTOwJ21cg= X-Received: by 2002:a05:6a00:10c7:b0:71d:f012:6ddc with SMTP id d2e1a72fcca58-71e4c185c15mr6364751b3a.16.1728774142439; Sat, 12 Oct 2024 16:02:22 -0700 (PDT) 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 References: <0f17e747ba8a7d740439e7a5bbd3cb00ab814960.camel@gentoo.org> In-Reply-To: <0f17e747ba8a7d740439e7a5bbd3cb00ab814960.camel@gentoo.org> From: Mitchell Dorrell Date: Sat, 12 Oct 2024 18:57:40 -0400 Message-ID: Subject: Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14 To: gentoo-dev@lists.gentoo.org Cc: python@gentoo.org Content-Type: multipart/alternative; boundary="000000000000a8581b06244f9831" X-Archives-Salt: 6a500a01-618f-4ab7-90b8-bdff5f14c80a X-Archives-Hash: 24de21650ef81f840518804005e51ebe --000000000000a8581b06244f9831 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 12, 2024, 14:03 Micha=C5=82 G=C3=B3rny wrot= e: > On Sat, 2024-10-12 at 10:12 +0200, Micha=C5=82 G=C3=B3rny wrote: > > 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: > > > > dev-lang/python3_14 > > dev-lang/python3_14t > > > > (Alternatives: python-3_14, python-freethreading-3_14? Though I think > > following PYTHON_TARGETS is cleaner here.) > > > > 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. > > > > Comments? > > Given all the opposition, I retract this. I hope my questions weren't interpreted as opposition. I'm mostly neutral, perhaps leaning a bit in favor. When someone complains that Portage suddenly installs Python 3.13 > freethreading or Python 3.14 on their systems, it's on you. > > -- > Best regards, > Micha=C5=82 G=C3=B3rny I like slots for saying "these are different versions of the same fundamental package, which you might want to install simultaneously, because dependent packages may or may not need a specific version.", so yes, on paper I agree that slots feel correct for different Python versions. However, if there's another aspect of compatibility (freethreading vs. non-freethreading), then I understand that slots don't handle that well, and neither do USE flags. I would _love_ to have something in between slots and USE flags -- perhaps call them VARIANT flags, where differing combinations of VARIANT flags can be installed simultaneously, but without carrying any implication of one VARIANT combination being "newer" than another. This would be fantastic for multilib systems that want different USE flags for x86 and amd64 builds (my 64-bit software stack GREATLY inflates my otherwise-minimal 32-bit stack). As another example, sci-chemistry/gromacs offers MPI support for clustering capabilities, but this actually impairs performance when running on a single machine, so there's good reason to desire installing both simultaneously (the ebuild already handles simultaneous single-precision and double-precision builds). This would be a major change to Portage, however, and I imagine we still need a short-term solution even if the VARIANT idea is embraced and implemented rapidly. Perhaps a pair of USE flags could control the compiling/installation of freethreading and non-freethreading builds, with a REQUIRED_USE mandating at least one of them? If not, I think separate packages might be the best (interim) solution unless/until a new Portage feature is implemented to handle it all more elegantly. -MD --000000000000a8581b06244f9831 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 12, 2024, 14:03 Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> wrote:
On Sat, 2024-10-12 at 10:12 +0200, Micha=C5=82 = G=C3=B3rny wrote:
> This naturally means that only the specific version requested (e.g. vi= a
> targets) would be installed, and no cross-slot autoupgrades would
> happen.=C2=A0 Ideally, I'd like to start doing that with Python 3.= 14 whose
> first alpha is expected next week.=C2=A0 Depending on how they handle<= br> > freethreading, we'd end up having the first or both of:
>
>=C2=A0 =C2=A0dev-lang/python3_14
>=C2=A0 =C2=A0dev-lang/python3_14t
>
> (Alternatives: python-3_14, python-freethreading-3_14? Though I think<= br> > following PYTHON_TARGETS is cleaner here.)
>
> As a side notice, the existing versions would probably remain as-is > until removal, since there's really no gain in splitting them, giv= en
> we'd have to retain compatibility with existing depstrings.
>
> Comments?

Given all the opposition, I retract this.

I hope my que= stions weren't interpreted as opposition. I'm mostly neutral, perha= ps leaning a bit in favor.

When someone c= omplains that Portage suddenly installs Python 3.13 freethreading or Python= 3.14 on their systems, it's on you.

--
Best regards,
Micha=C5=82 G=C3=B3rny

=
I like slots for saying "the= se are different versions of the same fundamental package, which you might = want to install simultaneously, because dependent packages may or may not n= eed a specific version.", so yes, on paper I agree that slots feel cor= rect for different Python versions. However, if there's another aspect = of compatibility (freethreading vs. non-freethreading), then I understand t= hat slots don't handle that well, and neither do USE flags.

I would _love_ to have something in= between slots and USE flags -- perhaps call them VARIANT flags, where diff= ering combinations of VARIANT flags can be installed simultaneously, but wi= thout carrying any implication of one VARIANT combination being "newer= " than another. This would be fantastic for multilib systems that want= different USE flags for x86 and amd64 builds (my 64-bit software stack GRE= ATLY inflates my otherwise-minimal 32-bit stack). As another example, sci-c= hemistry/gromacs offers MPI support for clustering capabilities, but this a= ctually impairs performance when running on a single machine, so there'= s good reason to desire installing both simultaneously (the ebuild already = handles simultaneous single-precision and double-precision builds).

This would be a major change to= Portage, however, and I imagine we still need a short-term solution even i= f the VARIANT idea is embraced and implemented rapidly.

Perhaps a pair of USE flags could control t= he compiling/installation of freethreading and non-freethreading builds, wi= th a REQUIRED_USE mandating at least one of them? If not, I think separate = packages might be the best (interim) solution unless/until a new Portage fe= ature is implemented to handle it all more elegantly.

-MD
--000000000000a8581b06244f9831--