[gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Mark Knecht]

So on one machine yesterday I did emerge -DuN @world which then
suggested the need for emerge @preserved-rebuild which I did over
night. This morning it was finished but suggested the need for a
second emerge @preserved-rebuild. As I don't need the machine right
now I kicked it off and will check it again later but I'm wondering
why in the world it needs to do this twice, compiling 52 packages the
first time and 50 packages the second time where most of the packages
in the first list were in the second list?

Is this setting up for an endless loop?

Most of the packages were part of Gnome or XFCE4.

Cheers,
Mark

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Alan McKinnon]

On Thursday 12 November 2009 16:43:15 Mark Knecht wrote:
> So on one machine yesterday I did emerge -DuN @world which then
> suggested the need for emerge @preserved-rebuild which I did over
> night. This morning it was finished but suggested the need for a
> second emerge @preserved-rebuild. As I don't need the machine right
> now I kicked it off and will check it again later but I'm wondering
> why in the world it needs to do this twice, compiling 52 packages the
> first time and 50 packages the second time where most of the packages
> in the first list were in the second list?
> 
> Is this setting up for an endless loop?
> 
> Most of the packages were part of Gnome or XFCE4.

I've been answering this question a lot lately :-)

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.

A later revdep-rebuild will sort out any (highly unlikely) remaining issues

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Mark Knecht]

On Thu, Nov 12, 2009 at 6:58 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Thursday 12 November 2009 16:43:15 Mark Knecht wrote:
>> So on one machine yesterday I did emerge -DuN @world which then
>> suggested the need for emerge @preserved-rebuild which I did over
>> night. This morning it was finished but suggested the need for a
>> second emerge @preserved-rebuild. As I don't need the machine right
>> now I kicked it off and will check it again later but I'm wondering
>> why in the world it needs to do this twice, compiling 52 packages the
>> first time and 50 packages the second time where most of the packages
>> in the first list were in the second list?
>>
>> Is this setting up for an endless loop?
>>
>> Most of the packages were part of Gnome or XFCE4.
>
> I've been answering this question a lot lately :-)
>
> 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.
>
> A later revdep-rebuild will sort out any (highly unlikely) remaining issues
>
> --
> alan dot mckinnon at gmail dot com

Thanks Alan. I always tend to do a revdep-rebuild -i anyway. Not sure
if it's required but old habits die hard.

Cheers,
Mark

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Mark Knecht]

On Thu, Nov 12, 2009 at 7:14 AM, Mark Knecht <markknecht@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 6:58 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> On Thursday 12 November 2009 16:43:15 Mark Knecht wrote:
>>> So on one machine yesterday I did emerge -DuN @world which then
>>> suggested the need for emerge @preserved-rebuild which I did over
>>> night. This morning it was finished but suggested the need for a
>>> second emerge @preserved-rebuild. As I don't need the machine right
>>> now I kicked it off and will check it again later but I'm wondering
>>> why in the world it needs to do this twice, compiling 52 packages the
>>> first time and 50 packages the second time where most of the packages
>>> in the first list were in the second list?
>>>
>>> Is this setting up for an endless loop?
>>>
>>> Most of the packages were part of Gnome or XFCE4.
>>
>> I've been answering this question a lot lately :-)
>>
>> 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.
>>
>> A later revdep-rebuild will sort out any (highly unlikely) remaining issues
>>
>> --
>> alan dot mckinnon at gmail dot com
>
> Thanks Alan. I always tend to do a revdep-rebuild -i anyway. Not sure
> if it's required but old habits die hard.
>
> Cheers,
> Mark
>

Again, thanks Alan. The second pass through finished up and the same
offending package (apparently e2fsprogs-libs ?) was still listed so
erasing the preserved_libs_registry file and using revdep-rebuild -i
suggests that the machine is clean again.

Cheers,
Mark

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * Regenerating GNU info directory index...
 * Processed 122 info files.

!!! existing preserved libs:
>>> package: sys-libs/e2fsprogs-libs-1.41.9
 *  - /lib/libblkid.so
 *      used by /bin/mount (sys-apps/util-linux-2.16.1)
 *      used by /bin/umount (sys-apps/util-linux-2.16.1)
 *      used by /sbin/blkid (sys-apps/util-linux-2.16.1)
 *      used by 10 other files
 *  - /lib/libuuid.so
 *      used by /bin/mount (sys-apps/util-linux-2.16.1)
 *      used by /bin/umount (sys-apps/util-linux-2.16.1)
 *      used by /sbin/blkid (sys-apps/util-linux-2.16.1)
 *      used by 362 other files
Use emerge @preserved-rebuild to rebuild packages using these libraries
gandalf ~ # rm /var/lib/portage/preserved_libs_registry
gandalf ~ # revdep-rebuild -ip
 * Configuring search environment for revdep-rebuild

 * Checking reverse dependencies
 * Packages containing binaries and libraries broken by a package update
 * will be emerged.

 * Collecting system binaries and libraries
 * Generated new 1_files.rr
 * Collecting complete LD_LIBRARY_PATH
 * Generated new 2_ldpath.rr
 * Checking dynamic linking consistency
[ 100% ]

 * Dynamic linking on your system is consistent... All done.
gandalf ~ # equery belongs /lib/libblkid.so
[ Searching for file(s) /lib/libblkid.so in *... ]
sys-libs/e2fsprogs-libs-1.41.9 (/lib/libblkid.so -> libblkid.so.1)
gandalf ~ # equery belongs /lib/libuuid.so
[ Searching for file(s) /lib/libuuid.so in *... ]
sys-libs/e2fsprogs-libs-1.41.9 (/lib/libuuid.so -> libuuid.so.1)
gandalf ~ #

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Alan McKinnon]

On Thursday 12 November 2009 18:19:02 Mark Knecht wrote:
> Again, thanks Alan. The second pass through finished up and the same
> offending package (apparently e2fsprogs-libs ?) was still listed so
> erasing the preserved_libs_registry file and using revdep-rebuild -i
> suggests that the machine is clean again.
> 
> Cheers,
> Mark
> 
> >>> Auto-cleaning packages...
> >>>
> >>> No outdated packages were found on your system.
> 
>  * Regenerating GNU info directory index...
>  * Processed 122 info files.
> 
> !!! existing preserved libs:
> >>> package: sys-libs/e2fsprogs-libs-1.41.9
> 
>  *  - /lib/libblkid.so
>  *      used by /bin/mount (sys-apps/util-linux-2.16.1)
>  *      used by /bin/umount (sys-apps/util-linux-2.16.1)
>  *      used by /sbin/blkid (sys-apps/util-linux-2.16.1)
> 

An easy way to check if things are OK is to run ldd on each of the "used by" 
files. None of them should list "Not found". If they do, portage has gotten 
itself confused and it's records are out of sync with reality.

There's not much portage can do about this as the problem is really with the 
ebuilds

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Mark Knecht]

On Thu, Nov 12, 2009 at 8:28 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Thursday 12 November 2009 18:19:02 Mark Knecht wrote:
>> Again, thanks Alan. The second pass through finished up and the same
>> offending package (apparently e2fsprogs-libs ?) was still listed so
>> erasing the preserved_libs_registry file and using revdep-rebuild -i
>> suggests that the machine is clean again.
>>
>> Cheers,
>> Mark
>>
>> >>> Auto-cleaning packages...
>> >>>
>> >>> No outdated packages were found on your system.
>>
>>  * Regenerating GNU info directory index...
>>  * Processed 122 info files.
>>
>> !!! existing preserved libs:
>> >>> package: sys-libs/e2fsprogs-libs-1.41.9
>>
>>  *  - /lib/libblkid.so
>>  *      used by /bin/mount (sys-apps/util-linux-2.16.1)
>>  *      used by /bin/umount (sys-apps/util-linux-2.16.1)
>>  *      used by /sbin/blkid (sys-apps/util-linux-2.16.1)
>>
>
> An easy way to check if things are OK is to run ldd on each of the "used by"
> files. None of them should list "Not found". If they do, portage has gotten
> itself confused and it's records are out of sync with reality.
>
> There's not much portage can do about this as the problem is really with the
> ebuilds
>
> --
> alan dot mckinnon at gmail dot com

Thanks. I'll star this conversation and try to remember that advice in
the future. Problem was the first time around it listed 3 or 4 and
then stated "and 362 others..." but didn't give the names. Clearly
something was confused!

Cheers,
Mark

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

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.


-- 
Neil Bothwick

"It compiled? The first screen came up? Ship it!" -- Bill Gates

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Alan McKinnon]

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

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Mark Knecht]

On Fri, Nov 13, 2009 at 10:42 AM, Alan McKinnon <alan.mckinnon@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

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Alan McKinnon]

On Friday 13 November 2009 21:46:04 Mark Knecht wrote:
> On Fri, Nov 13, 2009 at 10:42 AM, Alan McKinnon <alan.mckinnon@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?

The basic problem is that portage's idea of the state of the machine differs 
from reality. For a package manager, that's not a good thing as sooner or 
later it will do the wrong thing.

Detecting orphans is also an expensive process later so it's best to avoid it 
happening if possible


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Mark Knecht]

On Fri, Nov 13, 2009 at 12:57 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Friday 13 November 2009 21:46:04 Mark Knecht wrote:
>> On Fri, Nov 13, 2009 at 10:42 AM, Alan McKinnon <alan.mckinnon@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?
>
> The basic problem is that portage's idea of the state of the machine differs
> from reality. For a package manager, that's not a good thing as sooner or
> later it will do the wrong thing.
>
> Detecting orphans is also an expensive process later so it's best to avoid it
> happening if possible
>
>
> --
> alan dot mckinnon at gmail dot com

I agree that we want to be in agreement but then what are our options
if emerge @preserved-rebuild goes into an endless loop as it seems it
was doing yesterday? Do we just stop looping, wait until someone may
one day fix the ebuild, and then try again never knowing when things
will be correct again?

I had a problem show up last evening after I thought everything was
done. I went back for one last revdep-rebuild and then it decided to
tell me that there were wine libraries on the machine unowned by any
installed package. Now this machine hasn't had Wine on it in over a
year so I cannot understand why it would start telling me that today
but it did.

It seems to me that expensive or not it would be great to have a tool
that completely checked every single library on the machine if that's
what it takes. I thought revdep-rebuild was doing that but now I'm not
so sure.

Cheers,
Mark

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On Fri, 13 Nov 2009 14:19:26 -0800, Mark Knecht wrote:

> I agree that we want to be in agreement but then what are our options
> if emerge @preserved-rebuild goes into an endless loop as it seems it
> was doing yesterday?

Was it an endless loop? AIUI you emerged twice and the @preserved-rebuild
count decreased. In my experience, it can occasionally take a few runs to
clear the list, sometimes subsequent runs add packages that were not
there previously, but it all clears in the end, I have NEVER had to
resort to deleting the registry file manually.


-- 
Neil Bothwick

I'm not being rude. You're just insignificant.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Mark Knecht]

On Fri, Nov 13, 2009 at 2:38 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Fri, 13 Nov 2009 14:19:26 -0800, Mark Knecht wrote:
>
>> I agree that we want to be in agreement but then what are our options
>> if emerge @preserved-rebuild goes into an endless loop as it seems it
>> was doing yesterday?
>
> Was it an endless loop? AIUI you emerged twice and the @preserved-rebuild
> count decreased. In my experience, it can occasionally take a few runs to
> clear the list, sometimes subsequent runs add packages that were not
> there previously, but it all clears in the end, I have NEVER had to
> resort to deleting the registry file manually.
>
>
> --
> Neil Bothwick

If I don't run it forever then I don't think I can say it would never
clear up. Can't prove a negative, etc.

However, it did get to the point where it was complaining about two
packages and the number of files to be rebuilt went (IIRC) 52, 50, 50,
so I decide since it was rebuilding 50 packages the 2nd & 3rd times it
wasn't going to improve. Might not be true though.

- Mark

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

On Fri, 13 Nov 2009 15:00:33 -0800, Mark Knecht wrote:

> >
> > Was it an endless loop? AIUI you emerged twice and the
> > @preserved-rebuild count decreased. In my experience, it can
> > occasionally take a few runs to clear the list, sometimes subsequent
> > runs add packages that were not there previously, but it all clears
> > in the end, I have NEVER had to resort to deleting the registry file
> > manually.

> If I don't run it forever then I don't think I can say it would never
> clear up. Can't prove a negative, etc.

When you get identical package lists on subsequent runs, I think it's
fair to say it won't fix itself. This has never happened to me.

> However, it did get to the point where it was complaining about two
> packages and the number of files to be rebuilt went (IIRC) 52, 50, 50,
> so I decide since it was rebuilding 50 packages the 2nd & 3rd times it
> wasn't going to improve. Might not be true though.

I think it is being over-cautious, which results in packages being
rebuilt multiple time unnecessarily, but I's rather give it the chance to
fix itself. That said, I've never had a list anything like 50 packages
long, but I do update frequently.


-- 
Neil Bothwick

Why are love and relationships so confusing?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Dale]

Neil Bothwick wrote:
> On Fri, 13 Nov 2009 15:00:33 -0800, Mark Knecht wrote:
>
>   
>>> Was it an endless loop? AIUI you emerged twice and the
>>> @preserved-rebuild count decreased. In my experience, it can
>>> occasionally take a few runs to clear the list, sometimes subsequent
>>> runs add packages that were not there previously, but it all clears
>>> in the end, I have NEVER had to resort to deleting the registry file
>>> manually.
>>>       
>
>   
>> If I don't run it forever then I don't think I can say it would never
>> clear up. Can't prove a negative, etc.
>>     
>
> When you get identical package lists on subsequent runs, I think it's
> fair to say it won't fix itself. This has never happened to me.
>
>   

I had this happen to me the other day.  I ran preserved-rebuild 3 or 4 
times with the last two or three being the same.  I can't recall if I 
posted it here or not, I think I did tho, but I did eventually get it 
sorted by emerging packages in a certain order.  After that, it came 
back clean with nothing needing to be rebuilt.

I update about twice a week as a general rule.  Sort of depends.

Dale

:-)  :-) 

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Mark Knecht]

On Fri, Nov 13, 2009 at 3:13 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Fri, 13 Nov 2009 15:00:33 -0800, Mark Knecht wrote:
>
>> >
>> > Was it an endless loop? AIUI you emerged twice and the
>> > @preserved-rebuild count decreased. In my experience, it can
>> > occasionally take a few runs to clear the list, sometimes subsequent
>> > runs add packages that were not there previously, but it all clears
>> > in the end, I have NEVER had to resort to deleting the registry file
>> > manually.
>
>> If I don't run it forever then I don't think I can say it would never
>> clear up. Can't prove a negative, etc.
>
> When you get identical package lists on subsequent runs, I think it's
> fair to say it won't fix itself. This has never happened to me.
>
>> However, it did get to the point where it was complaining about two
>> packages and the number of files to be rebuilt went (IIRC) 52, 50, 50,
>> so I decide since it was rebuilding 50 packages the 2nd & 3rd times it
>> wasn't going to improve. Might not be true though.
>
> I think it is being over-cautious, which results in packages being
> rebuilt multiple time unnecessarily, but I's rather give it the chance to
> fix itself. That said, I've never had a list anything like 50 packages
> long, but I do update frequently.
>
It wasn't that I had 50 packages in the emerge -DuN @world. That was
something like 10. It was after that finished and I ran
@preserved-rebuild that it said 50 packages were effected by something
it found, but those 50 were all dependent on just one or two packages
that Alan was suggesting to me are held in the preserved database
file, or so I think.

Again, you know me...basically a flunky just trying to use my tool box
to play music even if I don't know how the tool box works...

- Mark

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

On Fri, 13 Nov 2009 17:06:02 -0800, Mark Knecht wrote:

> > I think it is being over-cautious, which results in packages being
> > rebuilt multiple time unnecessarily, but I's rather give it the
> > chance to fix itself. That said, I've never had a list anything like
> > 50 packages long, but I do update frequently.
> >  
> It wasn't that I had 50 packages in the emerge -DuN @world. That was
> something like 10. It was after that finished and I ran
> @preserved-rebuild that it said 50 packages were effected by something
> it found, but those 50 were all dependent on just one or two packages
> that Alan was suggesting to me are held in the preserved database
> file, or so I think.

I realised it was 50-odd in the rebuild list, but in my experience
multiple runs gradually reduces that number. Maybe portage could be more
intelligent about the order in which it re-emerges these packages, but
running it enough times always works for me.

Removing the registry is potentially risky because you could still have
packages linked to a library that is not managed by portage, and that
will never update. If someone finds a security hole in that library, you
could be in trouble.

"Fixing" the problem by deleting the registry is akin to fixing low oil
pressure in your car by disconnecting the warning light.


-- 
Neil Bothwick

We are THOR of Borg... your RFC compliant mailbox has been assimilated

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Alan McKinnon]

On Saturday 14 November 2009 01:13:06 Neil Bothwick wrote:
> > However, it did get to the point where it was complaining about two
> > packages and the number of files to be rebuilt went (IIRC) 52, 50, 50,
> > so I decide since it was rebuilding 50 packages the 2nd & 3rd times it
> > wasn't going to improve. Might not be true though.
> 
> I think it is being over-cautious, which results in packages being
> rebuilt multiple time unnecessarily, but I's rather give it the chance to
> fix itself. That said, I've never had a list anything like 50 packages
> long, but I do update frequently.
> 

The only relevant facts I have ever seen myself are that ldd was telling me a 
lib was required and portage had already told me via depclean that it 
wasn't...

It's totally possible that what the OP is running into is something I've never 
had to track down

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Alan McKinnon]

On Saturday 14 November 2009 03:06:02 Mark Knecht wrote:
> It wasn't that I had 50 packages in the emerge -DuN @world. That was
> something like 10. It was after that finished and I ran
> @preserved-rebuild that it said 50 packages were effected by something
> it found, but those 50 were all dependent on just one or two packages
> that Alan was suggesting to me are held in the preserved database
> file, or so I think.
> 

Yes, that's pretty much the scenario I was describing.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] emerge @ world -> @preserved-rebuild -> @preserved-rebuild -> what next?

[Erik]

Alan McKinnon skrev:
> On Saturday 14 November 2009 01:13:06 Neil Bothwick wrote:
>   
>>> However, it did get to the point where it was complaining about two
>>> packages and the number of files to be rebuilt went (IIRC) 52, 50, 50,
>>> so I decide since it was rebuilding 50 packages the 2nd & 3rd times it
>>> wasn't going to improve. Might not be true though.
>>>       

seems related to https://bugs.gentoo.org/show_bug.cgi?id=292622