Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14

[Mitchell Dorrell <mwd@psc.edu>]

[-- Attachment #1: Type: text/plain, Size: 2994 bytes --]

On Sat, Oct 12, 2024, 14:03 Michał Górny <mgorny@gentoo.org> wrote:

> On Sat, 2024-10-12 at 10:12 +0200, Michał Górny 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ł Górny


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

[-- Attachment #2: Type: text/html, Size: 3916 bytes --]