# emerge -p pingus clanlib [ebuild N ] dev-games/clanlib-0.6.5-r1 [ebuild R ] games-puzzle/pingus-0.6.0-r1 [ebuild R ] dev-games/clanlib-0.7.7 # emerge -p mplayer DirectFB [ebuild R ] media-video/mplayer-0.92 [ebuild R ] dev-libs/DirectFB-0.9.20 # emerge -p mozilla gtk+ [ebuild R ] net-www/mozilla-1.6 [ebuild R ] x11-libs/gtk+-2.2.4-r1 In these examples on my system, these packages weren't correctly ordered, despite the last package being before the first in a --emptytree USE="acpi acpi4linux apache2 async cjk dvdimap fbcon gimpprint gtk2 innodb \ maildir mmx mng mozcalendar mozsvg mpeg4 music openal pcap plotutils \ rage128 samba tiff unicode vim-with-x -apm -gnome -arts -mbox -python -gtk" My arbitrary USE flags. Reproducible: Always Steps to Reproduce: 1. try emerge -p packageB packageA where A depends on B 2. watch for packageB being emerged before A Actual Results: The first few I tried had the results listed. Expected Results: This is bad behaviour that probably explains why my last revdep-rebuild required a good 3 or 4 reorderings as compiles kept breaking. Was very annoying. Would have required more if I hadn't known some of the natural order.
I don't understand, why you want emerge to reorder this packages. Most of them are already merged, thus dependencies are satisfied, and i see no reason to do things in an order which is not the one the user specified. From emerge point of view, the ordering is perfectly correct. Now, from revdep-rebuild point of view, things are different. It has detected some broken packages, that for sure should be reemerged first, because in fact they are no more in a state to satisfy any dependencies. But that's something emerge can't guess and that's probably why its behavior is not the one you would expect. For me, the fix would simply be that revdep-rebuild does an "emerge -C broken packages" prior to reemerging anything. (Plus maybe a bit of /root/.revdep-rebuild temp file magic to be safe and know what is the remaining work in case an emerge fails, because once unmerge, broken packages won't be detected a second time). Once this done, emerge will follow the ordering implied by dependencies, like if it was a fresh install. Does this sounds correct or did i miss something?
> or did i miss something? I did... 'reemerge --oneshot' != 'unmerge + emerge', from virtuals and world points of view. Fixing this from revdep-rebuild would definitly makes things more complicated, so maybe changing emerge behavior is in fact the right approach, i don't know. Sorry for the noise then.
I found your comments interesting anyway. :) My other concern is that let's say I'm a user. Check out this. # emerge -p mozilla glibc These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-www/mozilla-1.6 [ebuild UD] sys-libs/glibc-2.3.2-r9 [2.3.3_pre20040207] You can't tell me that's proper behaviour... emerge should simply order in all cases. That is just safest.
Oh. And in this case, yes, updating just glibc would probably be a Bad Thing. :) Let's pretend it is some library only used by mozilla...
Eh, that's not fair, you have to find real world example :) Anyway, I understand the argument, but I think it is wrong to rely on this: if compiled against the new version of the lib your mozilla differs from what it would have been compiled against the old version, then you will have troubles anyway. It probably means that if the lib change again then mozilla won't link anymore, things like this, so this is not really an issue of sorting the emerge tasks, but more yet another instance of the "deps as described in ebuilds are not expressive enough to describe what will be real runtime deps" (openssl 0.9.6/0.9.7 beeing the most famous instance). If you are not in this kind of pathological case, i don't really see what sorting would change. At the contrary, user may have some much more important and precise requirements: % emerge -p vlc xfree These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] media-video/vlc-0.6.2-r1 [ebuild U ] x11-base/xfree-4.3.99.902-r1 Sure, vlc depends on xfree, but eh, i'm already right now using xfree, and what i want is to be able to watch a movie while new one is compiling :) About my comment #2, in fact, that's not a real problem, so my idea of unmerging first is still valid. A one line patch (okay, not heavily tested, almost not at all in fact) is enough to makes emerge recognize a notion of "temporary unmerges" using the --oneshot option. The behavior is simply that the package won't be removed from world file and virtuals, and thus, once reemerged again with --oneshot, it will be back to its original states. Using this, the sorting algorithm for revdep-rebuild would simply be: - emerge -C --oneshot --the-few-other-options [broken packages] - emerge --oneshot --the-few-other-options [broken packages] Patch follows for emerge. For revdep-rebuild, i'm too tired to try now (this is really not the kind of code i like to read before going to bed), so maybe later this weekend...
Created attachment 25565 [details, diff] oneshot-unmerge.patch
Regarding your vic/xfree example. You might end up having to compile vic twice, then. :) I'd rather have an option to override sorting for people in a hurry, and still have it by default. I think it'd help more than it would hurt, and would fix the revdep-rebuild simultaneously.
> Regarding your vic/xfree example. You might end up having to compile vic twice, then. :) Not this one more than any other other app that uses xfree. Deps reordering would really only be a preventive measure to randomly hide some potential bugs under particular very unlikely circumstancies, bugs that would anyway show up on most other installation where people would have emerged the packages in several steps instead of one. I don't say it would hurt, but imo it is still completly useless. To come back to the real issue, the revdep-rebuild one, i have a solution which is i think better than what i've descibed above: - drop both the "exact version" and "package name" in favor of a single "update in slot" mode. Sure, emerge doesn't support that, but it can be easily implemented by a separate python script as a workaround. - reorder the emerge tasks using the "emerge -p --emptytree" output. This was not possible in the the two previous modes, but makes sense now our target packages are the most up-to-date ones in the right slots. The ordering will then be similar to the one of a fresh install, so it should fix the issues you've seen. I will attach the helper python script i've made and a patch to revdep-rebuild.
Created attachment 25687 [details, diff] revdep-rebuild--in_slot_update.patch
Created attachment 25688 [details] smart-update.py to go in /usr/lib/gentoolkit/pym
Ok. I installed gentoo on a fresh machine and ran into this again. emerge --oneshot --nodeps -p =dev-php/php-4.3.10 =net-fs/samba-3.0.10 =net-libs/libwww-5.4.0-r2 PHP 4.3.10 failed to recompile due to a dependancy on libwww which needed recompiling... Personally I think the patch worked fine - any reason it never made it into the official release? configure:13422: gcc -o conftest -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib conftest.c -lm -lxmlparse -lxmltok 1>&5 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../../i686-pc-linux-gnu/bin/ld: warning: libmysqlclient.so.12, needed by /usr/X11R6/lib/libxmlparse.so, not found (try using -rpath or -rpath-link)
(In reply to comment #11) > Ok. I installed gentoo on a fresh machine and ran into this again. > emerge --oneshot --nodeps -p =dev-php/php-4.3.10 =net-fs/samba-3.0.10 =net- libs/libwww-5.4.0-r2 > > PHP 4.3.10 failed to recompile due to a dependancy on libwww which needed recompiling... Er, you specified ( or revdep did ) --nodeps, meaning portage will ignore dependencies. You can't use nodeps and then complain when portage does what you told it to do :) >Personally I think the patch worked fine - any reason it never made it into the >official release? Which patch? The patch from comment #10?
Oops. That'll teach me not to check my Yahoo! account. Yeah, had tried his script at the time. I'd have to see if it still works. As for the --nodeps thing. While yes, technically that means not considering dependancies, on the other hand, quietly reordering based on the ebuilds passed to it seems harmless. Especially if they impact each other. Of course if you have an alternate to using revdep-rebuild that now exists, I'll certainly switch to that. I doubt my gentoo system would've lasted these many years without it, though.
*** Bug 149604 has been marked as a duplicate of this bug. ***
*** Bug 151332 has been marked as a duplicate of this bug. ***
*** Bug 151831 has been marked as a duplicate of this bug. ***
*** Bug 164862 has been marked as a duplicate of this bug. ***
Same problem. x11-libx/xcb-utils changed library names libXCBRenderUtil -> libxcb-render-util. revdep-rebuild failed because (at least) of dependency x11-libs/gtk+ -> x11-libs/pango. emerge tries to build gtk+ first, but it needs pango, which is broken now.
In my refactored revdep-rebuild (bug #184042), I included an option to skip ordering altogether. Ordering isn't always necessary, and attempting to resolve package order definitely slows revdep-rebuild down. When ordering is required, I suppose I can add back the code that greps for the packages over a complete emerge -e. It's horribly slow, but most of the time users can just skip ordering altogether. Other options include: - (quickpkg and) unmerging the packages (possibly dangerous, would need a way to avoid unmerging toolchain packages) - *hiding* part of the vdb from portage so it *thinks* the packages are not installed (inelegant and scares me) I'm trying to see if there's a better way to fool portage into thinking a list of packages is not installed.
*** Bug 162661 has been marked as a duplicate of this bug. ***
Is this bug still valid?
Please test for this bug against revdep-rebuild in =app-portage/gentoolkit-0.2.4_rc3 and reopen if the bug still applies.
