[SOLVED] Cannot emerge world due to python

sam_ · Developer Joined: 14 Aug 2020 Posts: 2328

Thank you! Is it possible for you to grab the current emerge -pev @world --backtrack=0 output as well? If it's one particular issue I have in mind, then that'll still give us something useful as well.

Hu · Administrator Joined: 06 Mar 2007 Posts: 23446

penguinomicon · n00b Joined: 25 May 2024 Posts: 9 Location: Australia

penguinomicon · n00b Joined: 25 May 2024 Posts: 9 Location: Australia

sam_ · Developer Joined: 14 Aug 2020 Posts: 2328

Thanks. It took me a minute to see it, because the Portage output is pretty poor for this case.

I have two suggested theories:
1. You had something else which couldn't be rebuilt (which is common for these cases, and I need to finish my Portage patch to diagnose it; that's what -pev @world --backtrack=0 diagnoses) that you later unmerged or managed to depclean, and/or
2. It's an odd case with scons because the only thing holding you back is a python-any-r1 dep on something else (which is rare). autounmask can't suggest anything there, as it's not the problem, and the group of packages left in your output are all "minimal" (they're just dependencies of gpep517 & setuptools which scons needs), nothing else being dragged in by other packages.

As a way of working around 2 (though it should be fixed now), I notice that other distros are using CMake to build serf, and it might be worth us doing that too. I'll take a quick look at doing that.

EDIT: ... though I probably won't bother for now, as while Fedora have a patch to backport that to 1.3.x, it's quite large.

RayDude · Posted: Sat May 03, 2025 4:40 am Post subject:

Update: I'm trying the slow stable method... *crosses fingers*

Update: Yeah. That didn't work:

Update: This did: emerge -1vUD --backtrack=1000 @world, I'll continue...

Stand by.

szatox · Advocate Joined: 27 Aug 2013 Posts: 3650

RayDude · Posted: Sat May 03, 2025 3:26 pm Post subject:

I'm not going to be able to run 3.13 on all packages because some packages do not support 3.13.

I think Gentoo's automated python manager works well, considering the python package issues it has to deal with. However, I think the manager should detect when packages to be built do not support the latest version and automatically leave necessary down rev versions of python installed where necessary. It should also change the USE for the packages that need down rev versions so they install correctly. I don't mind having two versions of python installed, in fact I've had three many times in the past because package managers and upstream devs are often slow to update to the latest python version.

By the way, emerge -vq is really cool. I just did that by accident and I love how it shows the load average while keeping the noise output lower (unless that's a new feature of -q I hadn't noticed until now, oh well).
_________________
Some day there will only be free software.

cfgauss · l33t Joined: 18 May 2005 Posts: 749 Location: USA

My workaround for those applications that need different versions of Python packages than Gentoo's system Python provides is to run them in a venv and pip install the packages that that application needs. An example is Doom Emacs.

Hu · Administrator Joined: 06 Mar 2007 Posts: 23446

RayDude · Posted: Sat May 03, 2025 5:29 pm Post subject:

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3511 Location: Canada

You should follow the news item and do

emerge --deep --changed-use @world

that does resolve all python conflicts including jaraco (I spent some time trying to work around it as well)

However, it is not very well highlighted in the news item

szatox · Advocate Joined: 27 Aug 2013 Posts: 3650

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3511 Location: Canada

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2982

Hu · Administrator Joined: 06 Mar 2007 Posts: 23446

Although USE_EXPAND is configured from other variables, those variables are still under the control of the profile with local administrator override. I am not aware of any USE_EXPAND that would change their effective value in response to the user merging or unmerging a particular package.

As I understood the feature request, the following would happen:

The Gentoo developers declare python 3.Y ready, and python 3.X discouraged.
If the local system has no packages for which python 3.X is the best available version, then the system will switch to python 3.Y as its sole Python, as if by setting in the profile PYTHON_TARGETS="-* python3.Y" PYTHON_SINGLE_TARGET=python3.Y.
If the local system has at least one package for which python 3.X is the best available version (where packages that are unavailable due to a keyword mask or package.mask are considered not to exist for this purpose), then all such packages, and the supporting packages for those packages (recursively), implicitly get PYTHON_TARGETS="python3.X", on top of the system-wide PYTHON_TARGETS=python3.Y. The top-level "old" package will have PYTHON_TARGETS="python3.X python3.Y", and ignore the latter as unsupported. Its supporting packages will also have both, and may respect both if they have been ported to support python3.Y, resulting in those packages building for both python versions. The "old" package would presumably also need an implied PYTHON_SINGLE_TARGET="-* python3.X", which could be much trickier. If it requires a matching PYTHON_SINGLE_TARGET on all its supporting packages, then now those packages stay back, and conflict with any consumers which have been updated to PYTHON_SINGLE_TARGET=python3.Y (and require matching).

All that looks a little messy, but where I expect serious trouble is if a user was in the python3.Y only group, then decides to emerge a previously unused package which requires python3.X, and per this feature, Portage goes back and adds in python3.X to packages which didn't need it until the user tried to pull in this "old" package. Yes, the user will do exactly that if he wants the python3.X-using package more than he wants to avoid a rebuild, and if the user chooses that path via autounmask or manual keywording, that is fine. I just dislike the idea that Portage will take off "fixing" the flag mismatches without some confirmation from the user that this is desired. Currently, we have that confirmation in the form of requiring the user to trigger the autounmask and approve its changes. Perhaps autounmask could be more helpful in this area. Perhaps not. I rarely use it, so I don't know how well it handles this case. I recognize that autounmask also has one other shortcoming related to this feature: it never cleans up after itself. As I understand the proposed feature, Portage would quietly begin dropping PYTHON_TARGETS=python3.X from any package where it had been implied on, once there is no further need for that implied USE.

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2982

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3511 Location: Canada

C5ace · Posted: Sat May 03, 2025 11:37 pm Post subject:

I run my normal update on my desktop and 3 laptops. The only hiccup was with app-i18n/ibus-anthy.

This was fixed by adding a new file:
/etc/portage/package.use/00python

szatox · Advocate Joined: 27 Aug 2013 Posts: 3650

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2982

RayDude · Posted: Sun May 04, 2025 6:32 am Post subject:

Hu · Administrator Joined: 06 Mar 2007 Posts: 23446

szatox · Advocate Joined: 27 Aug 2013 Posts: 3650