• [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, st

    From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to All on Sat Oct 12 10:20:02 2024
    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


    -----BEGIN PGP SIGNATURE-----

    iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmcKL4gSHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOSuoH/3xN3bfkiRKY8Zoj0mvpDCVE3h2BJCSm GBG+REKjH/OR6B8bpLFwCHzwLuZw7ba61Qy+cTjyFf79wiQtB1MV8aP+5NL7baAu YPlh1mv58PlWfvmFpcukH+RhCAjmqQbmnkzA7RXpQGZSPyciJxrKte5XGTErMc95 QB5nRE5WLc6OcPnionWBJpasE9JcGCsxKvUCj1WaRxQDkFPs8lx5ocdPB4f36XNJ gLqJ4BvzwDpFk0Ywq2pj2l+miv40F3kcTT+ZughYcv1MIna3v4Prw5jxaiaWDpQr FqdixqNwT/WiuJ15U39iEpoze0pUo9K6i5ZGcbyslZ3a2JDPZD/SSh0=
    =HSzr
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)