On 12/10/24 11:13, Michał Górny wrote:
On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote:
On 12/10/24 10:12, Michał Górny wrote:
Comments?
I'm afraid it would lead to way too many packages and I'm not sure the
overall experience would be an improvement.
5 are too many?
potentially it is python_{version}_{variants} so at least 10*2 assuming
we keep around 3.{N..N+5} and we have two worthy variants.
Plus the chore of treecleaning older packages. Not sure if it is worth it.
With your proposed solution, if an user wants to have any version of
python what should ask to emerge?
Can you actually imagine having a Gentoo system with no Python
preinstalled, with an user actually needing to emerge one?
right now if I need a specific version of python I have to do emerge
=python-N* and usually it works as intended.
people would have to get used to do emerge python_{that specific N}
In fact, even today "emerge dev-lang/python" is probably a bad solution,
as it will lead to a beta/rc version on an ~arch system most
of the time.
An alternative for freethreading support wouldn't be to install both
from the same package python-3.14 and have the two PYTHON_TARGETS ?
I don't understand.
emerge =python-3.14 would install both a non-freethreading and a
freethreading version and it would satisfy 3_14 and 3_14t at the same.
lu
