Summary: | sys-apps/portage: app-arch/libarchive - dependency conflict (subslot related?) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daniel Pielmeier <billie> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | esigra, pacho |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 300071 |
Description
Daniel Pielmeier
![]() I can't reproduce. The ebuilds look all fine in CVS. I suspect this is something to do with the new subslots and how the package manager picks them up. This may be a duplicate of bug 461464. Please post the output of this command: emerge -pv1 app-arch/libarchive dev-util/cmake gnome-base/gvfs (In reply to comment #2) > This may be a duplicate of bug 461464. Please post the output of this > command: > > emerge -pv1 app-arch/libarchive dev-util/cmake gnome-base/gvfs emerge -pv1 app-arch/libarchive dev-util/cmake gnome-base/gvfs These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild U ] app-arch/libarchive-3.1.2-r1:0/13 [3.0.4-r1:0/0] USE="acl bzip2 e2fsprogs iconv lzma lzo%* xattr zlib -expat -nettle -static-libs" 4,422 kB [ebuild R ] dev-util/cmake-2.8.9 USE="ncurses qt4 vim-syntax -emacs {-test}" 0 kB [ebuild R ] gnome-base/gvfs-1.12.3-r1 USE="archive bluray cdda http udev -afp -avahi -bluetooth -doc -fuse -gdu -gnome-keyring -gphoto2 -ios -samba (-udisks*)" 0 kB Total: 3 packages (1 upgrade, 2 reinstalls), Size of downloads: 4,422 kB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: gnome-base/gvfs:0 (gnome-base/gvfs-1.12.3-r1::gentoo, installed) pulled in by >=gnome-base/gvfs-1.10.1[udisks,udev] required by (xfce-base/thunar-1.4.0::gentoo, installed) (gnome-base/gvfs-1.12.3-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) app-arch/libarchive:0 (app-arch/libarchive-3.1.2-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (app-arch/libarchive-3.0.4-r1::gentoo, installed) pulled in by app-arch/libarchive:0/0= required by (gnome-base/gvfs-1.12.3-r1::gentoo, installed) It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. You may want to try a larger value of the --backtrack option, such as --backtrack=30, in order to see if that will solve this conflict automatically. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (In reply to comment #3) > >=gnome-base/gvfs-1.10.1[udisks,udev] required by > (xfce-base/thunar-1.4.0::gentoo, installed) This one dependency may be the source of all your problems. It looks like gvfs ebuild no longer has a udisks USE flag. Maybe it will solve if you rebuild thunar too: emerge -pv1 app-arch/libarchive dev-util/cmake gnome-base/gvfs xfce-base/thunar (In reply to comment #4) > (In reply to comment #3) > > >=gnome-base/gvfs-1.10.1[udisks,udev] required by > > (xfce-base/thunar-1.4.0::gentoo, installed) > > This one dependency may be the source of all your problems. It looks like > gvfs ebuild no longer has a udisks USE flag. Maybe it will solve if you > rebuild thunar too: The stable version of gvfs temporarily had USE="udisks" unmasked by mistake, it was later corrected and masked again in base/package.use.mask Thunar allows installation of both [gdu,udev] or [udisks,udev] and it's defined only as a RDEPEND in the ebuild (no DEPEND) so Portage *should* be capable of being satisfied by it on the fly without re-emerging anything :-/ (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > >=gnome-base/gvfs-1.10.1[udisks,udev] required by > > > (xfce-base/thunar-1.4.0::gentoo, installed) > > > > This one dependency may be the source of all your problems. It looks like > > gvfs ebuild no longer has a udisks USE flag. Maybe it will solve if you > > rebuild thunar too: > > The stable version of gvfs temporarily had USE="udisks" unmasked by mistake, > it was later corrected and masked again in base/package.use.mask Okay, that explains it. > Thunar allows installation of both [gdu,udev] or [udisks,udev] and it's > defined only as a RDEPEND in the ebuild (no DEPEND) so Portage *should* be > capable of being satisfied by it on the fly without re-emerging anything :-/ He has to re-emerge it with USE=gdu enabled, because he has it disabled, as you can see in comment #3. (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > >=gnome-base/gvfs-1.10.1[udisks,udev] required by > > > > (xfce-base/thunar-1.4.0::gentoo, installed) > > > > > > This one dependency may be the source of all your problems. It looks like > > > gvfs ebuild no longer has a udisks USE flag. Maybe it will solve if you > > > rebuild thunar too: > > > > The stable version of gvfs temporarily had USE="udisks" unmasked by mistake, > > it was later corrected and masked again in base/package.use.mask > > Okay, that explains it. > > > Thunar allows installation of both [gdu,udev] or [udisks,udev] and it's > > defined only as a RDEPEND in the ebuild (no DEPEND) so Portage *should* be > > capable of being satisfied by it on the fly without re-emerging anything :-/ > > He has to re-emerge it with USE=gdu enabled, because he has it disabled, as > you can see in comment #3. Thank you both. So the problem was me having installed gvfs with use udisks while it was temporarily unmasked? (In reply to comment #7) > Thank you both. So the problem was me having installed gvfs with use udisks > while it was temporarily unmasked? Yeah, so the dep is satisfied by the installed version, since it was built before the flag got masked. Meanwhile, rebuilding it would break the || ( >=gnome-base/gvfs-1.10.1[udisks,udev] >=gnome-base/gvfs-1.10.1[gdu,udev] ) dependency, since udisks is now masked and you don't have USE=gdu enabled. (In reply to comment #8) > (In reply to comment #7) > > Thank you both. So the problem was me having installed gvfs with use udisks > > while it was temporarily unmasked? > > Yeah, so the dep is satisfied by the installed version, since it was built > before the flag got masked. Meanwhile, rebuilding it would break the || ( > >=gnome-base/gvfs-1.10.1[udisks,udev] >=gnome-base/gvfs-1.10.1[gdu,udev] ) > dependency, since udisks is now masked and you don't have USE=gdu enabled. So, there was nothing to do here and this can be closed as INVALID or WORKSFORME? Or is the bug open still for reason? unCCing libarchive maintainers (including myself) -> (In reply to comment #9) > So, there was nothing to do here and this can be closed as INVALID or > WORKSFORME? > Or is the bug open still for reason? Well, if portage output is confusing then maybe we can improve it somehow. Well, I CCed myself because I had a similar issue some days ago and I needed to figure out that a rebuild of affected packages was necessary. If portage can improve its message to show this tip, would be nice. If it's hard to do, no problem :) (In reply to comment #10) > (In reply to comment #9) > > So, there was nothing to do here and this can be closed as INVALID or > > WORKSFORME? > > Or is the bug open still for reason? > > Well, if portage output is confusing then maybe we can improve it somehow. Improving the output would definitely help. I was unable to figure out what went wrong. |