On Sat, Oct 12, 2024, 14:03 Michał Górny <mgo...@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
