big_daddy portage # /usr/bin/emerge =sys-apps/portage-2.2.8-r1::gentoo * IMPORTANT: 9 news items need reading for repository 'gentoo'. * Use eselect news to read news items. Calculating dependencies... done! [ebuild UD ] sys-apps/portage-2.2.8-r1 [2.2.10] !!! 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-2.2.8-r1:0/0::gentoo, ebuild scheduled for merge) pulled in by =sys-apps/portage-2.2.8-r1::gentoo (Argument) (sys-apps/portage-2.2.10:0/0::gentoo-guis, installed) pulled in by (no parents that aren't satisfied by other packages in this slot) !!! Enabling --newuse and --update might solve this conflict. !!! If not, it might help emerge to give a more specific suggestion. big_daddy portage # /usr/bin/emerge --version Portage 2.2.10 (default/linux/amd64/13.0/desktop, gcc-4.8.2, glibc-2.18-r1, 3.7.4-gentoo x86_64) big_daddy portage # Reproducible: Always
I've tried everything possible that I could think of. I checked out versions of portage down to 2.2.7. Using the installed 2.2.10 version. Various options as suggested --newuse, --upgrade, --backtrack=1000. It would not upgrade, downgrade or even rebuild the same slot if the ebuild was from a different repo than the installed version. Copying the ebuild back to the original overlay I installed it from, works for rebuilding. Trying to upgrade to 9999 after successfully rebuilding, results in the same repo conflict error.
Created attachment 373878 [details] debug.log output emerge -uNpd sys-apps/portage &> debug.log
"sys-apps/portage-2.2.10:0/0::gentoo-guis, installed", looks like your Portage is from a "gentoo-guis" overlay, whatever that is Shouldn't you be reporting this to the overlay maintainers instead?
Adding --nodeps to the options breaks the repo conflict. Also it will downgrade itself from -9999 to -2.2.8-r1. any portage version installed from the gentoo repo seems to work fine installing any other version even if it is from a different repo. Once portage is installed form a non-gentoo repo, the only way to emerge another portage version is for that version to also be in that same repo or use the --nodeps option.
I am an overlay maintainer for the gentoo-guis overlay. It was only in my local copy of that repo for testing before I committed the ebuild and version bump to gentoo-x86. This bug is an internal bug in portage code.
(In reply to Brian Dolbec from comment #2) > Created attachment 373878 [details] > debug.log output > > emerge -uNpd sys-apps/portage &> debug.log It looks like you have sys-apps/portage::gentoo-guis in your world file. In this case emerge's answer would be correct. Please provide the debug output for the command in comment #0.
Thanks, I didn't think about an entry in the world file. Since I had unmasked 9999, I used =sys-apps/portage-2.2.10 and sometimes have added ::gentoo-guis to test changes before committing them to CVS. I need to be more careful to add -1 to options when doing that. But it did reveal some bugs :) brian@big_daddy ~/Dev/git/portage $ cat /var/lib/portage/world | grep portage ... app-portage/porthole sys-apps/portage sys-apps/portage::gentoo-guis brian@big_daddy ~/Dev/git/portage $ So, there is 2 problems then with portage's handling then. 1) multiple entries for the same package & slot in world. repo should not be a part of slot for determining dupes in the world file. 2) emerge needs to be smarter about reporting repo conflicts. The --newuse --upgrade and --backtrack options suggested do nothing to solve them. Since emerge does not report the real cause of the conflict, it leads major frustration. Possibly we should add an {yet another :( } option to ignore (remove for dep calcs) the repo setting from the world file?
(In reply to Brian Dolbec from comment #7) > So, there is 2 problems then with portage's handling then. > > 1) multiple entries for the same package & slot in world. repo should not be > a > part of slot for determining dupes in the world file. Is that a problem somehow? > > 2) emerge needs to be smarter about reporting repo conflicts. > The --newuse --upgrade and --backtrack options suggested do nothing > to solve them. > Since emerge does not report the real cause of the conflict, it leads > major frustration. > It gave it's best to tell you: From your debug.log: sys-apps/portage::gentoo-guis required by @selected It told you that there's this sys-apps/portage::gentoo-guis atom in your world file. > Possibly we should add an {yet another :( } option to ignore (remove for dep > calcs) the repo setting from the world file? No. You explicitly asked for portage from that repo and you got portage from that repo.