last night I was trying to emerge -avuDN world and ran updates. I notice that udev-87-r1 was stable. as of that day pre my sync. but emerge -avuDN world didn't pick it up. i ran emerge -avuDN sytem and that found it fine. this is not normal behavior and may be a bug in portage.
Reopen with emerge --info.
Created attachment 89672 [details] emerge info was going to put it on but had to wait until I got home. it's in the attachment
added emerge info
Please attach the output of `emerge -ped world` (small d for --debug).
Created attachment 89676 [details] emerge -ped world This is my emerge -ped world
Created attachment 90050 [details] emerge -ped world hmm.. possible related problem. I added[ebuild R ] dev-ml/lablgtk-2.4.0 USE="opengl svg* -debug -doc -glade -gnome -gnomecanvas" 0 kB howver when I ran emerge -avuDN world it didn't find it at all. or when I ran emerge avuDN system. Note: I hadn't actually let it update yet. I'm attaching another emerge -ped world. grep-ing lablgtk comes up with nothing
(In reply to comment #6) > grep-ing lablgtk comes up with nothing Is it listed in /var/lib/portage/world?
(In reply to comment #7) > (In reply to comment #6) > > grep-ing lablgtk comes up with nothing > > Is it listed in /var/lib/portage/world? > nope. neither of them are... should they be if they were dependancies of something else? isn't udev part of system?
(In reply to comment #8) > nope. neither of them are... should they be if they were dependancies of > something else? isn't udev part of system? udev is an indirect dependency of system, and should therefore be pulled in on any deep update. Are you able to reproduce the issue where udev updates are not pulled in? If so, please attach an emerge --pretend --debug log for the command demonstrating that problem. lablgtk not being in your `emerge -ped world` output generally indicates that nothing depends on it. In that case, updates of that package will not be pulled in by deep world updates. We may add an "all" package set (for bug 96088) that will pull in all possible updates. I'm not sure how useful that is though. Generally, the package should be added to the world file via `emerge --noreplace <atom>` or removed via `emerge --depclean`.
(In reply to comment #9) > (In reply to comment #8) > > nope. neither of them are... should they be if they were dependancies of > > something else? isn't udev part of system? > > udev is an indirect dependency of system, and should therefore be pulled in on > any deep update. Are you able to reproduce the issue where udev updates are > not pulled in? If so, please attach an emerge --pretend --debug log for the > command demonstrating that problem. > > lablgtk not being in your `emerge -ped world` output generally indicates that > nothing depends on it. In that case, updates of that package will not be > pulled in by deep world updates. We may add an "all" package set (for bug > 96088) that will pull in all possible updates. I'm not sure how useful that is > though. Generally, the package should be added to the world file via `emerge > --noreplace <atom>` or removed via `emerge --depclean`. > real hard to say what the state of these issues are at the moment... lablgtk might not be in world because according to me it's no longer installed (didn't think to check earlier). and not sure what I needed for when I filed that part of the bug. I can't say about udev... no updates (stable) 5o it since I filed.
... world doesn't handle all? I kinda thought it did? ... if used with the -e option.
(In reply to comment #11) > ... world doesn't handle all? I kinda thought it did? ... if used with the -e > option. No, world includes system and packages explicitly merged by the user. WIth --deep, it includes deep dependencies of those (such as udev). If you're able to reproduce this, please reopen with emerge --pretend --debug output for the command that behaves unexpectedly.
Created attachment 95760 [details] emerge info am updating emerge info for new attachement as I'm reinstalling gentoo and encountered I think a related problem.
Created attachment 95762 [details] emerge -pvuDNd world ok here's the issue I'm installing gdm in this new install. x11-libs/gtk+-2.8.19 failed. cairo needs the X flag set so I set X in the make.conf and run said command without d option and get a bunch of updates... I let it run... try to emerge gdm again... same thing I do an emerge -av cairo. [ebuild R ] x11-libs/cairo-1.0.4 USE="X* -doc -glitz -png" 0 kB my emerge -avuDN world should have rebuilt cairo
Created attachment 95763 [details] emerge -pvd cairo
see prior comments - forgot to reopen on those
(In reply to comment #14) > ok here's the issue I'm installing gdm in this new install. > > x11-libs/gtk+-2.8.19 failed. > cairo needs the X flag set Actually, you've observed the expected behavior. Nothing that is installed depends on cairo and cairo is not in the world (or system) set, so it's not pulled into the depgraph. If you had run `emerge -uDN gdm`, then it would have pulled cairo into the depgraph like you wanted.
Now that I think about it, your original problem can be explained by the fact that emerge does not create a complete dependency graph. The problem is that portage's dep_check() function does not return atoms that are already satisified, so the dependecies of those satisfied atoms may not be fully accounted for in some circumstances. This issue is related to comments on bug 16365.
btw sorry about being an idiot (I should know better) on the last one... I'll look at the one your referring. I was actually thinking I had seen cairo pulled in by X or something else...
If --update and --deep are specified, portage shouldn't skip any dependencies. When the depgraph is created, a fakedb is created along with it. That fakedb is used with dep_check and only has packages added to it after matching atoms returned by prior calls to dep_check.
(In reply to comment #20) > If --update and --deep are specified, portage shouldn't skip any dependencies. > When the depgraph is created, a fakedb is created along with it. That fakedb is > used with dep_check and only has packages added to it after matching atoms > returned by prior calls to dep_check. Yes, that's right. Now I don't see any way for udev to be left out unless devfsd was satisfying the dep. We'd be able to see something like that if we had --debug ouput for the command that behaves unexpectedly...
