Hello, Historically, all versions of CPython were slotted in a single package, i.e.:
dev-lang/python:3.N 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. 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! 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.: dev-lang/python3_N 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? -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part