Python 3.12 upgrade requires python_targets_python3_11

[nitro322]

Hi, all. I realize there are a couple other posts about the Python 3.12 upgrade already, but I thought my particular question was different enough that a separate thread was appropriate.

I do not set PYTHON_TARGETS or PYTHON_SINGLE_TARGET in make.conf, instead letting portage handle the upgrades as needed. I'd expect it to be pretty seamless, but it's not. I'm pasting the output from my emerge -Dua @world below for reference (unfortunately, there are QT and KDE upgrades where their own dependency warnings, so this is a very long list - I didn't want to edit out any potentially important details, though).

My main question is around the python_targets_python3_11 requirement for many of the installed python packages. Why do I need to add that to package.use in order to upgrade to 3.12? or more specifically, why is that necessary? I get that if 3.11 and 3.12 are both installed then I'd need the USE flags for both to be enabled... but can portage not handle that more gracefully?

I run into this issue every time there's a python version upgrade - the upgrade is blocked unless I explicitly enable the older version, then upgrade everything, then once built I have to manually remove the USE flags for the old version and rebuild everything, then I can finally uninstall the old version of python. There are almost always some other dependency issues in there as well to further complicate things, like newer versions of apps needing to be manually unmasked to support the new stable version of python, but we can set that aside for now as well.

I stopped setting PYTHON_TARGETS a while back because I thought portage would automate these upgrades and make things easier for me, but it really doesn't, and no other version upgrades w/ dependencies seem to require such a high level of maintenance with every upgrade. I'd like to understand why.

Am I doing something on my system that still causes the need for manual intervention every time (I should note I run into these issues on all of my systems, so it's not a one-off)? or is there just inherent limitation with being able to seamlessly manage an upgrade of this nature?

As a follow-up, if this is just the way it is, is there a simpler / fewer step process to handle the upgrade than I described a couple paragraphs above? I'm very interested in simplifying manual maintenance tasks these days, and would appreciate any suggestions on that front.

Here's the upgrade output followed by emerge --info. Like I asked above, is there anything I'm doing "wrong" on this particular system that's complicating the upgrade and requiring additional manual steps?

Edit: Kept getting an "Error in posting" message when trying to post this. Maybe it doesn't like the length? Here are links to the upgrade and info output instead:

https://www.legroom.net/public/emerge-upgrade.txt

https://www.legroom.net/public/emerge-info.txt
_________________
https://www.legroom.net/

[Hu]

I have seen threads where people have specific packages that are not yet ready for python3.12, and so those packages need to be built for python3.11. As part of the planned change, the profiles changed so that, absent local overrides, Portage builds for python3.12 only. If building for python3.12 only is broken for a package, then you get an error. One quick workaround for that error is to add a local override to enable python3.11 for the package that does not support python3.12. However, that can lead to a cascade, as every Python package needed to support the overridden package will (usually) then want python3.11 enabled too.

One way to get in to trouble, which may or may not apply to your systems, is to have packages which ought to be rebuilt for python3.12, but are not part of the dependency graph from @world with your chosen options. Portage assumes such packages must not be rebuilt (because you have not given it permission to do so), but then also observes that if they are not rebuilt, then dependencies are not satisfied. That leads to a dependency error, because you have (by omission) created conflicting requirements. This can be avoided by ensuring that Portage is instructed to rebuild, all in one step, all packages that need a rebuild for USE flag / dependency changes.

[hagar-dunor]

I posted basically the same story there
This can probably be merged.

[cameta]

The same problem here with cdemu

[cameta]

[

[tld]

I ran into the same thing with this update with media-libs/avidemux-plugins, that is where it required exactly one of those. I had to expressly set it's python_single_target_python3_11 USE flag in my /etc/portage/package.use in order to do the update. Thought that seemed odd.

EDIT: Just to clarify, I went ahead and temporarily added that python_single_target_python3_11 USE flag for media-libs/avidemux-plugins and went ahead with the switch to 3.11 and everything went fine.

Tom

[myga]