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? - Mark
