Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 506214 - sys-apps/portage-2.2.10 fails to resolve a slot conflict with itself due to a repo change.
Summary: sys-apps/portage-2.2.10 fails to resolve a slot conflict with itself due to a...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Dependencies (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-30 04:02 UTC by Brian Dolbec
Modified: 2014-03-31 18:09 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
debug.log output (debug.log.xz,168.56 KB, application/x-xz)
2014-03-30 07:22 UTC, Brian Dolbec (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Dolbec (RETIRED) gentoo-dev 2014-03-30 04:02:18 UTC
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
Comment 1 Brian Dolbec (RETIRED) gentoo-dev 2014-03-30 07:15:52 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.
Comment 2 Brian Dolbec (RETIRED) gentoo-dev 2014-03-30 07:22:15 UTC
Created attachment 373878 [details]
debug.log output

emerge -uNpd sys-apps/portage &> debug.log
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2014-03-30 07:31:44 UTC
"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?
Comment 4 Brian Dolbec (RETIRED) gentoo-dev 2014-03-30 08:09:30 UTC
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.
Comment 5 Brian Dolbec (RETIRED) gentoo-dev 2014-03-30 08:11:37 UTC
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.
Comment 6 Sebastian Luther (few) 2014-03-30 19:18:02 UTC
(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.
Comment 7 Brian Dolbec (RETIRED) gentoo-dev 2014-03-31 17:59:32 UTC
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?
Comment 8 Sebastian Luther (few) 2014-03-31 18:09:27 UTC
(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.