| Summary: | sys-libs/e2fsprogs-libs blocked by sys-libs/com_err and sys-libs/ss | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Dave Kemper <saint.snit> |
| Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge --color n --pretend --debug sys-fs/e2fsprogs | ||
|
Description
Dave Kemper
2011-08-17 05:46:03 UTC
Bug 234907 comment 37 gives the simplest workaround of the lot: masking sys-libs/com_err and sys-libs/ss. However, this does not work for my case. (It is unclear to me whether this workaround was intended only to fix the mit-krb5 package, or any package which generates this impossible set of dependencies.) It looks like the blocker isn't going to solve unless you update app-crypt/mit-krb5, since the old version that you have installed is what's pulling in the obsolete sys-libs/ss-1.39 package:
(sys-libs/ss-1.39::__unknown__, installed) pulled in by
sys-libs/ss required by (app-crypt/mit-krb5-1.5.3-r1::gentoo, installed)
Maybe something like this will solve it:
emerge -1 app-crypt/mit-krb5 sys-fs/e2fsprogs
(In reply to comment #2) > Maybe something like this will solve it: > > emerge -1 app-crypt/mit-krb5 sys-fs/e2fsprogs Yes, that made portage happy: Calculating dependencies... done! [ebuild N ] virtual/os-headers-0 [ebuild N ] sys-apps/keyutils-1.2-r2 [ebuild N ] sys-libs/e2fsprogs-libs-1.41.12 USE="nls" [ebuild U ] sys-apps/util-linux-2.19.1 [2.12r-r5] USE="cramfs%* ncurses%* unicode%* -loop-aes% -old-linux% -slang% (-uclibc)" [uninstall ] sys-libs/ss-1.39 [blocks b ] sys-libs/ss ("sys-libs/ss" is blocking sys-libs/e2fsprogs-libs-1.41.12) [uninstall ] sys-libs/com_err-1.39 [blocks b ] sys-libs/com_err ("sys-libs/com_err" is blocking sys-libs/e2fsprogs-libs-1.41.12) [ebuild U ] sys-fs/e2fsprogs-1.41.12 [1.39] [blocks b ] <sys-fs/e2fsprogs-1.41.8 ("<sys-fs/e2fsprogs-1.41.8" is blocking sys-libs/e2fsprogs-libs-1.41.12, sys-apps/util-linux-2.19.1) [ebuild U ] app-crypt/mit-krb5-1.9.1 [1.5.3-r1] USE="keyutils%* pkinit%* threads%* -openldap% -test% -xinetd%" So that leaves me with two followup questions. 1. Is this a case of a missing dependency? If portage had pulled in app-crypt/mit-krb5 on its own, the build would have been able to proceed. 2. After reading the comments in bug 234907, I'm a little concerned about running this command as-is: there were multiple reports that the removal of sys-libs/ss and sys-libs/com_err breaks wget. If the installs and uninstalls proceed in the order above, would that cause the sys-fs/e2fsprogs update -- following the two uninstalls -- to fail? Should I do a --fetchonly run first (as per bug 234907 comment 7)? (In reply to comment #3) > 1. Is this a case of a missing dependency? If portage had pulled in > app-crypt/mit-krb5 on its own, the build would have been able to proceed. You can check for reverse dependencies like this: emerge -pv --depclean app-crypt/mit-krb5 > 2. After reading the comments in bug 234907, I'm a little concerned about > running this command as-is: there were multiple reports that the removal of > sys-libs/ss and sys-libs/com_err breaks wget. If the installs and uninstalls > proceed in the order above, would that cause the sys-fs/e2fsprogs update -- > following the two uninstalls -- to fail? It should work flawlessly, since sys-libs/e2fsprogs-libs is merged into place before the obsolete packages are unmerged. > Should I do a --fetchonly run first (as per bug 234907 comment 7)? You can if you want to. Better yet, install busybox with USE=static and check busybox --help to verify that the wget applet is enabled. Then if wget breaks then you can always replace it with a symlink to busybox. (In reply to comment #4) > (In reply to comment #3) > > 1. Is this a case of a missing dependency? If portage had pulled in > > app-crypt/mit-krb5 on its own, the build would have been able to proceed. > > You can check for reverse dependencies like this: Portage can only tell me about dependencies/reverse dependencies that it knows about. I'm wondering if this is a case that it should know about (i.e. whether this is an actual bug), or whether user intervention is expected in this situation. > It should work flawlessly, since sys-libs/e2fsprogs-libs is merged into place > before the obsolete packages are unmerged. Sorry, you're right, I misinterpreted the output -- it is of course sys-libs/e2fsprogs-libs, not sys-fs/e2fsprogs, that replaces the two older sys-libs packages. (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > 1. Is this a case of a missing dependency? If portage had pulled in > > > app-crypt/mit-krb5 on its own, the build would have been able to proceed. > > > > You can check for reverse dependencies like this: > > Portage can only tell me about dependencies/reverse dependencies that it knows > about. I'm wondering if this is a case that it should know about (i.e. whether > this is an actual bug), or whether user intervention is expected in this > situation. If it doesn't have any reversed dependencies, then you should either remove it with --depclean, or add it to your world file like this: emerge --noreplace app-crypt/mit-krb5 This is mentioned at the beginning of the FAQ, in the "Why is it that emerge does not update all packages?" section: http://www.gentoo.org/proj/en/portage/doc/faq.xml (In reply to comment #6) > If it doesn't have any reversed dependencies, then you should either remove it > with --depclean, or add it to your world file It has no reverse dependencies, so yes, it should be in the world file. Had it been, would that have included it in the dependency graph for "emerge -1 sys-fs/e2fsprogs"? My understanding is that the world file is only consulted when doing an update to world, not when doing a targeted update of a specific package. (My system is no longer in that state, so I can't test this directly.) (In reply to comment #7) > Had it been, would that have included it in the dependency graph for "emerge -1 > sys-fs/e2fsprogs"? No. Even if it wasn't, we plan to eventually solve that automatically (see bug 290818). Note that you can usually avoid this kind of problem by using `emerge -uD world` to automatically pull in all of the necessary updates with a single command. > My understanding is that the world file is only consulted > when doing an update to world, not when doing a targeted update of a specific > package. (My system is no longer in that state, so I can't test this > directly.) If you enable --complete-graph then the world file will always be consulted, in order to detect and prevent breakage of any reverse dependencies. This mode is also automatically activated in cases when packages such as sys-libs/ss and sys-libs/com_err need to be automatically removed, since we want to prevent breakage of reverse dependencies. For example, this particular mode was triggered your attached emerge output, where it successfully detected the dependency on sys-libs/ss and prevented it from being broken. Perhaps we should mark this bug as a duplicate of bug 290818? (In reply to comment #8) > No. Even if it wasn't, we plan to eventually solve that automatically (see bug > 290818). Yes, my issue sounds exactly like a manifestation of that bug's initial description: putting another package on the command line resolved it, but portage could have theoretically figured out which package it needed on its own. > Note that you can usually avoid this kind of problem by using `emerge > -uD world` That's the exact command I'm trying to avoid. :) At the moment it's impractical on this box for several reasons. *** This bug has been marked as a duplicate of bug 290818 *** |
