Hi,

even the most recent portage 2.2.0_alpha90 has difficulties handling
@preserved-rebuild especially after many binary emerge operations.

It tries to re-emerge the same packages again and again.
As a last resort I have to remove
/var/lib/portage/preserved_libs_registry.
But after that the old libraries are still hanging around and
revdep-rebuild won't since there aren't any broken libs or binaries
just some which are linked against old versions.
Is there an elegant way to find these old libraries? (Removing them
would alert revdep-rebuild afterwards).


Thanks for a hint,
Helmut.

On Mon, 12 Mar 2012 09:53:29 +0100, Helmut Jarausch wrote:

> Is there an elegant way to find these old libraries? (Removing them
> would alert revdep-rebuild afterwards).

man qfile and look at the section on finding orphan files.

Emerge portage-utils if you don't have qfile.


--
Neil Bothwick

mandelbug /man'del-buhg/ n.
[from the Mandelbrot set] A
bug whose underlying causes are so complex and obscure as to make
its behavior appear chaotic or even non-deterministic. This term
implies that the speaker thinks it is a Bohr bug, rather than
a heisenbug. See also schroedinbug.

> man qfile and look at the section on finding orphan files.
>
> Emerge portage-utils if you don't have qfile.

I just ran
# find /usr/lib* -type f -print0 | xargs -0 qfile -o | more

an was suprised how much orphans there are, already excluding the python
and perl stuff.

Here's some suprising stuff:

/usr/lib64/systemd/system/canberra-system-shutdown-reboot.service
/usr/lib64/systemd/system/console-kit-daemon.service
/usr/lib64/systemd/system/canberra-system-shutdown.service
/usr/lib64/systemd/system/udev-trigger.service
/usr/lib64/systemd/system/udev-control.socket
/usr/lib64/systemd/system/dbus.service
/usr/lib64/systemd/system/acpid.service
/usr/lib64/systemd/system/console-kit-log-system-restart.service
/usr/lib64/systemd/system/bluetooth.service
/usr/lib64/systemd/system/udev-kernel.socket
/usr/lib64/systemd/system/udev.service
/usr/lib64/systemd/system/alsa-store.service
/usr/lib64/systemd/system/console-kit-log-system-start.service
/usr/lib64/systemd/system/udev-settle.service
/usr/lib64/systemd/system/canberra-system-bootup.service
/usr/lib64/systemd/system/dbus.socket
/usr/lib64/systemd/system/alsa-restore.service
/usr/lib64/systemd/system/console-kit-log-system-stop.service
....
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libmudflapth.so.0.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/crtend.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgfortran.la
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/crtprec80.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgomp.a
....

the gcc stuff is multiple pages long. But I don't think it's a good idea
to start messing with gcc's files.
And what's with the systemd stuff? I never even installed it.

This is a fresh stage3 install from about a week ago.

Any thoughts?

On Mon, Mar 12, 2012 at 1:53 AM, Helmut Jarausch
<jarausch@igpm.rwth-aachen.de> wrote:
> Hi,
>
> even the most recent portage *2.2.0_alpha90 has difficulties handling
> @preserved-rebuild especially after many binary emerge operations.
> It tries to re-emerge the same packages again and again.
> As a last resort I have to remove /var/lib/portage/preserved_libs_registry.
> But after that the old libraries are still hanging around and revdep-rebuild
> won't since there aren't any broken libs or binaries just some which are
> linked against old versions.
> Is there an elegant way to find these old libraries? (Removing them would
> alert revdep-rebuild afterwards).
>
> Thanks for a hint,
> Helmut.
>

Hi,
I haven't tried Neil's method so I cannot comment on that.

Personally I actually start with

revdep-rebuild -ip

to see if anything is flagged. If there is then I run

equery depends whatever-was-found

and

equery belongs whatever-was-found

to see what uses (if anything) and what owns (if anything)
whatever-was-found. If nothing uses or owns then I delete it by hand.

It's labor intensive. Possibly Neil's metthod gets around some of
that. However I've used this for years and seldom had too many things
to clean up, and what I have had wasn't too difficult to work though.
There were some issue with Flash on one of my machine last week that
took awhile to dig through.

I try to do my machine once every couple of months.

HTH,
Mark

On 03/12/2012 01:23:21 PM, Michael Hampicke wrote:

> man qfile and look at the section on finding orphan files.
>
> Emerge portage-utils if you don't have qfile.

I just ran
# find /usr/lib* -type f -print0 | xargs -0 qfile -o | more

an was suprised how much orphans there are, already excluding the
python

and perl stuff.

Here's some suprising stuff:

/usr/lib64/systemd/system/canberra-system-shutdown-reboot.service


SNIP

I've found out a strange effect.

Many files in /usr/lib64 are NOT recorded by portage but only the
corresponding names in

/usr/lib

Therefore I've used

find -L /usr/lib -regextype posix-extended -regex '.*.so(.[0-9])+'
-type f -print0 | xargs -0 qfile -o | more


which says I don't have a single orphan on my machine.

Here /usr/lib is a symlink to /usr/lib64

Helmut.

> Here /usr/lib is a symlink to /usr/lib64

Now that you mention it: /usr/lib is supposed to be a symlink to
/usr/lib64 on my workstation too (like it is on all my other machines).
But it's not. Seems like something went wrong during installation. Maybe
a bad stage3 image. I created the symlink manually and now emerge -e world.