Summary: | sys-apps/portage-2.2.10 fails to resolve a slot conflict with itself due to a repo change. | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Brian Dolbec <dolsen> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | debug.log output |
Description
Brian Dolbec (RETIRED)
2014-03-30 04:02:18 UTC
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. |