1 |
Duncan <1i5t5.duncan@×××.net> posted pan.2009.01.22.20.21.28@×××.net, |
2 |
excerpted below, on Thu, 22 Jan 2009 20:21:28 +0000: |
3 |
|
4 |
> The problem was that I ended up with a mix of some "current" partitions |
5 |
> and some backup partitions and a package database that wasn't at all in |
6 |
> sync with what was actually on disk. |
7 |
|
8 |
More to the point, I did have binpkgs and could thus reinstall current |
9 |
and get what was running and what portage thought was installed back in |
10 |
sync, but it left behind a bunch of stale old library files and etc, that |
11 |
weren't removed, because portage thought the new version (with a |
12 |
different filename) was already installed, and thus didn't do the cleanup |
13 |
of the old installed version it would have normally done when upgrading. |
14 |
|
15 |
I had to do a lot of manual stuff like |
16 |
|
17 |
for candidatefile in /usr/lib64; do; |
18 |
equery b $candidatefile |
19 |
done |
20 |
|
21 |
Then I'd scan the output and for every file that didn't have an owner, |
22 |
I'd have to decide whether it was a legitimate file, config or other file |
23 |
not actually tracked by portage, or whether it was an old stale left- |
24 |
over. If it was the latter, I'd delete it. |
25 |
|
26 |
I realized that had everything been in sync, if portage had actually |
27 |
known what was installed, I'd have been able to upgrade and it would have |
28 |
automatically handled the cleanup as it normally does. As I said, I |
29 |
learned my lesson, and won't be making /that/ mistake again! |
30 |
|
31 |
-- |
32 |
Duncan - List replies preferred. No HTML msgs. |
33 |
"Every nonfree program has a lord, a master -- |
34 |
and if you use the program, he is your master." Richard Stallman |