Enormous amounts of unresolved blockers. Example: ----- * Error: circular dependencies: (dev-lang/python-3.9.16:3.9/3.9::gentoo, ebuild scheduled for merge) depends on (virtual/libcrypt-2:0/2::gentoo, ebuild scheduled for merge) (buildtime_slot_op) (sys-libs/libxcrypt-4.4.28-r2:0/1::gentoo, ebuild scheduled for merge) (runtime) (sys-libs/glibc-2.36-r5:2.2/2.2::gentoo, ebuild scheduled for merge) (buildtime) (dev-lang/python-3.9.16:3.9/3.9::gentoo, ebuild scheduled for merge) (buildtime) * Note that circular dependencies can often be avoided by temporarily * disabling USE flags that trigger optional dependencies. !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-lang/python-exec:2 (dev-lang/python-exec-2.4.9:2/2::gentoo, ebuild scheduled for merge) USE="(native-symlinks) -test" PYTHON_TARGETS="(pypy3) (python3_10) (python3_11) (python3_8) (python3_9)" pulled in by dev-lang/python-exec[python_targets_python3_9(-)] required by (dev-lang/python-3.9.16:3.9/3.9::gentoo, ebuild scheduled for merge) USE="ensurepip gdbm hardened ncurses readline sqlite ssl verify-sig xml -bluetooth -build -examples -lto -pgo -test -tk -valgrind" (dev-lang/python-exec-2.4.6-r1:2/2::gentoo, installed) USE="" PYTHON_TARGETS="(pypy3) python2_7 python3_6 python3_7 (python3_8) (-python3_9)" pulled in by >=dev-lang/python-exec-2:2/2=[python_targets_python3_6(-),-python_single_target_jython2_7(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),python_single_target_python3_6(+)] required by (dev-util/glib-utils-2.56.4:0/0::gentoo, installed) USE="" PYTHON_SINGLE_TARGET="python3_6 -python3_5 -python3_7" PYTHON_TARGETS="python3_6 -python3_5 -python3_7" ----- Here, as the ebuild for python-exec-2.4.6-r1 is no longer in tree, it isn't loading the corresponding one from /var/db/pkg and uses some information to block on the dependency version installed in the system. It should accept a more recent version, as it will if the older ebuild was available in the tree. Reproducible: Always Steps to Reproduce: 1.Install Gentoo as you choose. 2.Keep a look out for security vulnerabilities using glsa-check. 3.Try to update vulnerable packages (or world, after a while). 4.Python upgrades are also close to impossible as is. Actual Results: Portage has unresolved blockers due to not using the stored ebuilds for older packages. Upon providing the ebuilds for installed packages (var/db/pkg) into the current tree, portage can properly resolve installed pkg dependencies and upgrade the system. Expected Results: Portage should load the ebuilds in /var/db/pkg before trying to resolve dependencies. Otherwise, it assumes an older package requires a specific version of dependency (say 1.0), refusing to resolve on an dependency on version 1.0.1. When I first started using Gentoo (mid 2000s) this was not an issue and blockers were very, very rare, only usually happen if there was a library change that affected the base system. Currently, if you only plan to do security upgrades or be a little out of date on updates, ebuilds are superceded and removed from the tree and the system becomes unable to update without major, hours long efforts.
How long since the last update? PYTHON_TARGETS="python3_6 -python3_5 -python3_7" Seems pretty old.
This bug feels like one filed out of frustration rather than something specific we can address. Some notes: - Blockers mean the ebuild contains a !x or !!x dependency so collisions are ignored temporarily between them or they cannot be co-installed at all, even temporarily (respectively). You're talking about *conflicts* which are something else. - There was a news item specifically about the libxcrypt migration which made clear people should upgrade, and the news item was published well in advance to give people in a position like yours an opportunity to upgrade ahead of time. We knew it would be one of those awkward transition points which makes it harder (not impossible) to upgrade an older system. - Using existing packages in /var/db/pkg wouldn't help your situation because 'emerge --sync' will have changed the eclasses and such as well. See bug 303403 for something similar to the spirit of your request, though. - Even if it could use a large amount of existing packages, it would take a long time to backtrack so much, and you'd end up with a massive number of skipped upgrades. - Portage isn't always great at actually explaining the issue. Your output is truncated (please don't do that, nor did you include the command used) but often one needs to run something like 'emerge -pev @world --backtrack=0' (only with -p/--pretend) to diagnose issues with an old system to emerge --deselect anything removed. See also bug 257009 and bug 760783. - No emerge --info in this bug. Please provide it. We're happy to work through issues like this on IRC (#gentoo on libera) and I regularly help people to upgrade very old systems indeed.
(In reply to Sam James from comment #2) > This bug feels like one filed out of frustration rather than something > specific we can address. > > Some notes: > - Blockers mean the ebuild contains a !x or !!x dependency so collisions are > ignored temporarily between them or they cannot be co-installed at all, even > temporarily (respectively). You're talking about *conflicts* which are > something else. > > - There was a news item specifically about the libxcrypt migration which > made clear people should upgrade, and the news item was published well in > advance to give people in a position like yours an opportunity to upgrade > ahead of time. We knew it would be one of those awkward transition points > which makes it harder (not impossible) to upgrade an older system. > (I would also say that various other news items have mentioned "please do a full upgrade" and the Python news items would also be a good point to actually do such an upgrade...)
If you haven't updated, let's say for a year, it may be hard to update. Consider these options: 1) if you don't have that many services, a new installation and migration may be a quicker solution 2) discover the last time you fully updated your system, then update your portage tree to +1year and try to update. Then continue again moving portage +1year until your portage tree is the current one. For very old installations not updated for several years, path 2 can be really time consuming especially if it's a slow machine.
Hi all, I apologize for any mistake in the bug reporting, this snippet may not related to the bug reported but another issue with Portage that I had encountered. I have had a recently installed stage 3 Gentoo that, after a month or so, couldn't update due to missing ebuilds. So that is quite frustrating. Would a full emerge output be appropriate or should I also provide details about the ebuilds? This does seem like bug 303403, which will cause rebuilds that I don't think are required.
