Austin S Hemmelgarn posted on Wed, 09 Dec 2015 14:04:06 -0500 as excerpted:
> Agreed. It's not too bad fixing a Gentoo system (as long as > /var/lib/portage/world is still correct, you can just nuke the installed > package database and emerge world, it'll take time, but it will get your > system in a guaranteed consistent state). For sufficiently loose values of "consistent", yes, as I found out by experience. But it can be done, and I do have the experience to prove it. What happens in practice is that while yes, as long as @world is correct you can install to current and have all those files tracked again as appropriate, if your package installation database is missing or out of sync with what's actually on your filesystem(s), where the new version of various packages will replace older files as they come across them during the install process (subject to CONFIG_PROTECT of course, this part isn't the problem), the problem is actually where the files of the actually installed but untracked version differ from those of the version you're installing. I think the last bug I tracked down to having a stale file from an old version still around, was nearly two years after the initial disaster and recovery. It was some shell script (something to do with eselect IIRC) that had changed installed bindir location between package versions, and the bug was that due to path ordering, the stale version that hadn't been replaced by the reinstall and wasn't removed like it normally would have been when the old version was uninstalled, because my installed package database was out of sync with the backup I had used, was being executed as that bindir came earlier in the path, than the bindir for the updated version that was in the current package. So yes it did work and I was back in business, but I was tracing bugs down due to stray orphan files that hadn't been cleaned up by the out of sync installation database package uninstall, for two years! I wouldn't exactly call that "consistent", tho it /was/ consistent /enough/ to get back in business, if with lingering bugs to track down to still stale orphan files for years afterward. (FWIW, that'd be less of an issue on my own installation now, even if the installed package database got similarly out of sync, because on my system I'm running a unified root/usr and bin/sbin, now, with symlinks /usr -> . and /sbin -> bin, so all normal executables ultimately end up in /bin, and all normal libraries in /lib64, with /lib -> lib64, as well. No-multilib so I don't have to worry about that angle. Portage handles the symlinks just fine, tho I've filed I believe three bugs in total due to individual ebuild scripts (1, resolved/fixed) or cmake (2, one resolved/obsolete as the new version works, one still open, that I'm having to work around) doing the wrong thing.) > On something using dpkg or > rpm though, it's got the potential to be almost impossible to recover > from without a significant amount of low-level knowledge of the package > manager's installation database. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
