I expected no conflict for a standard portage update. But today I ran into this: Updating portage from 3.0.63 to 3.0.63-1 fails on many servers here: > emerge -a1 portage > ... > [pulls many changes due to python-11 -> 12] > ... > [ebuild U ] sys-apps/portage-3.0.63-r1 [3.0.63] PYTHON_TARGETS="python3_12* -python3_11*" > > > !!! Multiple package instances within a single package slot have been pulled > !!! into the dependency graph, resulting in a slot conflict: > > sys-apps/portage:0 > > (sys-apps/portage-3.0.63-r1:0/0::gentoo, ebuild scheduled for merge) USE="(ipc) native-extensions rsync-verify (xattr) -apidoc -build -doc -gentoo-dev (-selinux) -test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11" pulled in by > sys-apps/portage (Argument) > > (sys-apps/portage-3.0.63:0/0::gentoo, installed) USE="(ipc) native-extensions rsync-verify (xattr) -apidoc -build -doc -gentoo-dev (-selinux) -test" PYTHON_TARGETS="python3_11 (-pypy3) -python3_10 -python3_12" pulled in by > sys-apps/portage[python_targets_python3_11(-)] required by (app-admin/webapp-config-1.55-r3:0/0::gentoo, installed) USE="portage" PYTHON_TARGETS="python3_11 -python3_10" > > >=sys-apps/portage-2.1.10.3[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?] required by (app-portage/gentoopm-0.5.0:0/0::gentoo, installed) USE="-test" PYTHON_TARGETS="python3_11 (-pypy3) -python3_10 -python3_12" > > >=sys-apps/portage-3.0.57[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?] required by (app-portage/gentoolkit-0.6.5:0/0::gentoo, installed) USE="" PYTHON_TARGETS="python3_11 (-pypy3) -python3_10 -python3_12" > > [...] My question is: I can for sure find a solution to work-around this (e.g. enable python3_11 too for a while). However, I am more interested in a fool-proof, standard way out of such a situation. As I have NO python USE flag tweaks applied, only defaults, I'd expect to upgrade smoothly without issues. I do: (1) emerge --sync (2) emerge -a1 portage Well, obviously, this time we have a portage update PLUS the python upgrade from 11 to 12. But anyway, shouldn't a default USE flag configuration (NO python tweaks) always work? Extra info: I am dealing with production systems here, that are updated only once a month. Personally I had no such issues on workstations that receive updates more regularely. What is your recommendation for a fool-proof update procedure? Thanks
Please upgrade to app-admin/webapp-config-1.55-r4.
Thanks. That was not my point, though. I was asking for a *general* update strategy. The point is that upgrading portage first, then the rest, is not working in the above case. But I won't insist.
(In reply to m1027 from comment #2) > Thanks. That was not my point, though. > > I was asking for a *general* update strategy. The point is that upgrading > portage first, then the rest, is not working in the above case. > > But I won't insist. Portage used to say "there's an update available for me, please take it" unconditionally. It was updated for bug 722748 to not do that if there's a pending PYTHON_TARGETS change. In this case, the only real thing you could do is follow the Python news item and defer the default change until a time of your choosing.
(In reply to m1027 from comment #2) > I was asking for a *general* update strategy. The point is that upgrading > portage first, then the rest, is not working in the above case. Bugzilla is really not the place to ask for general advice. I would suggest asking in IRC, mailing lists, or the forums.
Great link to the bug report that addressed exactly my question! So, for my currently failing standard Gentoo update procedure (scripts) I'll try to fix that by another initial check when *not* to upgrade portage first. I will try to find help elsewhere though on how to programmatically check whether a python_targets change is pending.
