• Re: [gentoo-user] Python upgrade problem, maybe???

    From Eli Schwartz@21:1/5 to Dale on Sun May 4 06:50:01 2025
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------h20x1WHeQg1m0YaDRKoRGCwv
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    On 5/4/25 12:29 AM, Dale wrote:
    So I can either leave it with it set to use both or do individual
    packages settings, which can be quite a few packages? 

    My thinking is this.  Leave it with it set to both and only have two
    lines in packages.use.  Then I can comment out those lines to see if everything has caught up so I can just remove those lines, until the
    next big upgrade.  Two lines with emerge/portage managing what is used
    might be safer and more stable than me trying to force it one way or the other given I might forget.  I don't mind having both python 3.12 and
    3.13 on here at the same time.  It should be a temporary thing. 

    I'd like to have a easy way to manage this but at the same time, make
    sure I have a stable system.  KDE and some other stuff has enough quirks already, adding a mixed up python won't likely help much.  LOL 


    Yes, that sounds quite okay. Personally, I do per-package settings, but, well... I'm a software developer who develops software written in
    python, so I have a biiiit more patience than most people for juggling
    lots of python packages for multiple versions. :) Don't be me. :)



    Just so I'm clear on where my live OS stands, this is the current
    package.use setting.


    */* PYTHON_TARGETS: -* python3_12 python3_13
    */* PYTHON_SINGLE_TARGET: -* python3_13


    This is the output of my normal emerge update with the above setting. 


    root@Gentoo-1 / # emerge -aukDN world

    These are the packages that would be merged, in order:

    Calculating dependencies... done!
    Dependency resolution took 45.20 s (backtrack: 0/500).


    Total: 0 packages, Size of downloads: 0 KiB

    !!! The following installed packages are masked:
    - sys-kernel/gentoo-sources-6.14.0::gentoo (masked by: package.mask) /etc/portage/package.mask/package.mask:
    # =media-libs/opencv-4.10.0

    For more information, see the MASKED PACKAGES section in the emerge
    man page or refer to the Gentoo Handbook.


    Nothing to merge; quitting.

    root@Gentoo-1 / #


    Sounds perfect. :)



    So at the moment, my main OS is happy with that setting, no skipping anything.  I figure in a week or so, most other packages will catch up,
    due to the bug reports being filed, and then when the number of packages
    get small, I can then do individual packages in package.use or unmerge
    those packages if I don't need them.  I figure --depclean will take care
    of python when it is all clear. 


    Hopefully yes. There's no great guarantee since there's usually a very
    small tail end of packages which are very challenging to upgrade and
    take absolutely ages to migrate to newer python due to upstream
    developers not yet supporting it, and it needing "work", but whether
    those packages are important to any given person is very
    situation-dependent.

    Hopefully kicad is your only issue. That one is tracked by https://bugs.gentoo.org/952659 and using ACCEPT_KEYWORDS="**" will
    install kicad-9999.ebuild, which does support python 3.13.

    (Not saying you want to install totally unstable packages. But on the
    other hand, this does imply it's close to being ready. So... good news,
    right?)


    --
    Eli Schwartz

    --------------h20x1WHeQg1m0YaDRKoRGCwv--

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

    wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCaBbv6wUDAAAAAAAKCRCEp9ErcA0vV6D9 AQC1DC7HSTeuwSWdO6Eyqp/VrXa33dxy82YnF4ZlB+JMiQD+N7/f65R82aedblhqT83M6HjsJqJt Czn1orGDQWa3dg8=
    =u+Jj
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eli Schwartz@21:1/5 to Dale on Sun May 4 06:20:01 2025
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------8Z8xIniW3ruo1SUgxcIQDmel
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    On 5/3/25 11:49 PM, Dale wrote:
    Howdy,

    I decided to go the safer route with the python upgrade.  I do my
    compiles in a chroot and then copy packages over and emerge with -k on
    the main OS.  I did the first step in chroot, copied over and installed
    on main OS.  I then did the same again with the second step.  That all
    went well enough.  The last step tho, it spits out a lot of things that
    are not pleased with the update.  I'm thinking if I leave my package.use
    at step two until next week, those packages may catch up.  It seems some packages I have installed don't support the new default python yet. 
    This is the error part. 


    WARNING: One or more updates/rebuilds have been skipped due to a
    dependency conflict:

    dev-python/gpep517:0

    [...]

    dev-python/flit-core:0

    [...]

    dev-python/installer:0

    [...]

    dev-libs/boost:0

    [...]

    dev-python/cython:0

    [...]

    dev-python/setuptools:0

    [...]

    dev-python/six:0

    [...]

    dev-python/packaging:0

    [...]

    dev-python/setuptools-scm:0

    [...]

    dev-python/jaraco-collections:0

    [...]

    dev-python/jaraco-functools:0

    [...]

    dev-python/jaraco-text:0

    [...]

    dev-python/more-itertools:0

    [...]

    dev-python/platformdirs:0

    [...]                                                                                             

    dev-python/wheel:0

    [...]

    dev-python/trove-classifiers:0

    [...]


    Most of these packages are "interconnected core infrastructure, that is,
    they are the packages you need in order to build *other* python
    software. The exception here is:

    - boost, which is a major runtime package -- and a dependency of kicad.

    - cython -- used to build other packages, in theory packages can run it
    as either an importable python library or as a command line tool, in
    both cases as part of building a package but obviously in the latter
    case you don't necessarily need to build it for python 3.12

    For the most part, as long as you have a single package on your system
    using python 3.12 you will need to build this whole set of packages for
    python 3.12


    As you can tell, it wants to continue with some packages which is fine.


    Yup, for the packages which it doesn't complain about it can do a
    consistent and safe update without issues (one of the benefits of doing
    it in the safe two-stage upgrade! :) :) :))


    I'm just concerned about the ones where it says it is skipping.  Should
    I go back to this setting in package.use which is step two and stay
    there for now, which means both old 3.12 and 3.13 are supported? 



    */* PYTHON_TARGETS: -* python3_12 python3_13
    */* PYTHON_SINGLE_TARGET: -* python3_13


    This is the one that causes the error.


    */* PYTHON_TARGETS: -* python3_13
    */* PYTHON_SINGLE_TARGET: -* python3_13


    I'm thinking it is safe to leave at step two since it will use whichever
    is the latest python the package supports but want to be sure. 


    Setting both python targets is "easy", vs managing exactly which
    packages are a dependency of some 3.12-only package like kicad. But
    there's nothing wrong with setting them per-package as well, and setting
    them per-package can in some cases result in spending much less time
    building compiled packages for versions of python that you don't
    actually need (because no apps actually use that library for the old
    version of python).



    --
    Eli Schwartz

    --------------8Z8xIniW3ruo1SUgxcIQDmel--

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

    wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCaBbpkAUDAAAAAAAKCRCEp9ErcA0vV9rp AQC55arEkC3Q4TBXhl6C9YC4rzLyKvYHUgJtiqs6bSUGtAEA7pYJGrXAQUI1fxF+Ml90ITiBrCnQ vziX2IikElOjtwI=
    =EqMm
    -----END PGP SIGNATURE-----

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