> > > The logic is: > > > > > > Rebuild busted packages that portage already knows about > > > (@preserved-rebuild), then get rid of oudated packages and finally > > > revdep-rebuild to fix anything that --depclean broke. > > > > > > @preserved-rebuild is getting very good at what it does lately > > > (supported in all recent portage version including stable IIRC), as > > > is --depclean, so revdep-rebuild seldom finds anything to do these > > > days. > > > > > > -- > > > Alan McKinnon > > > > If revdep-rebuild does everything that @preserved-rebuild does and > > more, why run @preserved-rebuild at all? > > @preserved-rebuild does it correctly, does not break your system and > does not leave it in an indeterminate state while you spend hours > trying to figure out what went on. > > revdep-rebuild does all those things (and also gets around to fixing > broken libs while taking it's own sweet time to do it). > > So they are not really the same thing at all.
I'm not saying they're the same, I'm saying it looks like @preserved-rebuild does a subset of the things revdep-rebuild does. Why run @preserved-rebuild followed by revdep-rebuild if the end result is the same as running revdep-rebuild? I'm sure I'm missing something here but I don't know what it is. - Grant > Basically, portage removes old .so files when doing upgrades. If the > so-name changes, packages using that file are now broken. > revdep-rebuild was a phase 1 effort to repair that damage after the > fact, and it was good at that. > > @preserved-rebuild is a feature in portage that won't remove old .so > files until the last binary linking to it is removed. IOW, things still > work meanwhile. It's analogous to the Unix style of deleting files - if > you app still has a handle to a file and the file is deleted, your app > does not notice the difference as from it's POV the delete has not > happened yet
