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