On Fri, Nov 13, 2009 at 12:57 PM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > On Friday 13 November 2009 21:46:04 Mark Knecht wrote: >> On Fri, Nov 13, 2009 at 10:42 AM, Alan McKinnon <alan.mckin...@gmail.com> > wrote: >> > On Friday 13 November 2009 14:39:52 Neil Bothwick wrote: >> >> On Thu, 12 Nov 2009 16:58:15 +0200, Alan McKinnon wrote: >> >> > Almost invariably it's an automagic dependency where the offending >> >> > package is not in DEPEND. If you have been through the cycle at least >> >> > once, it is safe to delete /var/lib/portage/preserved_libs_registry >> >> > and continue on your way. >> >> >> >> Won't that leave orphaned libraries hanging around since they aren't >> >> removed until emerges complete successfully? I've seen this behaviour >> >> before, where the list gets shorter each time and let it run its course. >> >> It may take longer, but you know it's safe. >> > >> > Interesting point. My tests before indicated that a full --depclean >> > sorted everything out, but I can't be certain. @preserved-rebuild deletes >> > orphans once it's complete, but it would be nice to verify what happens >> > otherwise. >> > >> > Unfortunately, it's been a long time since any of my machines got stuck >> > in this loop. I must have earned some good joss in recent months... -- >> > alan dot mckinnon at gmail dot com >> >> If this problem is fundamentally due to dependencies not in DEPEND >> then is there any evidence that it's big a problem? I.e. - there >> aren't many packages that create the loop from what I've seen so far. >> >> I've had this issue show up on all the machines I've updated this >> week, but it was always (I think) the same packages that caused the >> problems. As Neil suggested, at least on one machine the number of >> offending packages did seem to go down, but it would never go to zero >> as far as I can tell. (I did it 3 times on one box just to convince >> myself but emerging 50 packages gets boring.) While I haven't bug >> reported it I suspect someone will jump on this and a few days or >> weeks from now it won't exist, at least for these packages. >> >> Other than disk space what's the technical downside of some libraries >> being stranded. Will this somehow leave applications pointing at old >> library binaries? > > The basic problem is that portage's idea of the state of the machine differs > from reality. For a package manager, that's not a good thing as sooner or > later it will do the wrong thing. > > Detecting orphans is also an expensive process later so it's best to avoid it > happening if possible > > > -- > alan dot mckinnon at gmail dot com
I agree that we want to be in agreement but then what are our options if emerge @preserved-rebuild goes into an endless loop as it seems it was doing yesterday? Do we just stop looping, wait until someone may one day fix the ebuild, and then try again never knowing when things will be correct again? I had a problem show up last evening after I thought everything was done. I went back for one last revdep-rebuild and then it decided to tell me that there were wine libraries on the machine unowned by any installed package. Now this machine hasn't had Wine on it in over a year so I cannot understand why it would start telling me that today but it did. It seems to me that expensive or not it would be great to have a tool that completely checked every single library on the machine if that's what it takes. I thought revdep-rebuild was doing that but now I'm not so sure. Cheers, Mark
