# revdep-rebuild fragen

## Yonathan

mahzeit.

bei einem revdep-rebuild bekomme ich immer als zu emergendes paket: xmms-mad heraus, das ist doch aber maskiert und ich wollte es eigentlich nicht wieder ins system holen. wie finde ich raus wer es braucht, bzw warum es neu emerged werden soll oder was kann ich dagegen tun?

```
randir enotice # revdep-rebuild -p

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... done.

  (/root/.revdep-rebuild.1_files)

Collecting complete LD_LIBRARY_PATH... done.

  (/root/.revdep-rebuild.2_ldpath)

Checking dynamic linking consistency...

  broken /usr/lib/xmms/Input/libxmmsmad.so (requires  libxmms.so.1)

  broken /usr/lib/avifile-0.7/divx4.la (requires /usr/lib/libaviplay.la)

  broken /usr/lib/avifile-0.7/divx4.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/divx4.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/divx4.la (requires /-lstdc++)

  broken /usr/lib/avifile-0.7/divx4.la (requires /-lstdc++)

  broken /usr/lib/directfb-0.9.22/inputdrivers/libdirectfb_sdlinput.la (requires /-lstdc++)

  broken /usr/lib/directfb-0.9.22/systems/libdirectfb_sdl.la (requires /-lstdc++)

  broken /usr/lib/libimlib-tiff.la (requires /usr/lib/libgdk_imlib.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkio.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkdeui.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkdesu.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkwalletclient.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkdecore.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libDCOP.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkdefx.la)

  broken /usr/lib/xmms/Input/libmpc.la (requires /usr/lib/libmusepack.la)

  broken /usr/lib/xmms/Input/libmpc.la (requires /usr/lib/libxmms.la)

 done.

  (/root/.revdep-rebuild.3_rebuild)

Assigning files to ebuilds... done.

  (/root/.revdep-rebuild.4_ebuilds)

Evaluating package order...

[color=red]Warning: Failed to resolve package order.

Will merge in "random" order![/color]

Possible reasons:

- An ebuild is no longer in the portage tree.

- An ebuild is masked, use /etc/portage/packages.keyword

  and/or /etc/portage/package.unmask to unmask it

..... done.

  (/root/.revdep-rebuild.5_order)

All prepared. Starting rebuild...

emerge --oneshot -p =media-plugins/xmms-mad-0.8

These are the packages that would be merged, in order:

Calculating dependencies

!!! All ebuilds that could satisfy "=media-plugins/xmms-mad-0.8" have been masked.

!!! One of the following masked packages is required to complete your request:

- media-plugins/xmms-mad-0.8 (masked by: package.mask)

# Diego Pettenò <flameeyes@gentoo.org> (23 Oct 2006)

# Pending removal 23 November for multiple bugs

# Use anything but this, like media-sound/audacious

# media-sound/amarok media-sound/mpd media-sound/rhythmbox

# media-sound/muine media-sound/banshee

For more information, see MASKED PACKAGES section in the emerge man page or

refer to the Gentoo Handbook.

[color=red]revdep-rebuild failed to emerge all packages

you have the following choices:[/color]

- if emerge failed during the build, fix the problems and re-run revdep-rebuild

    or

- use -X or --package-names as first argument (trys to rebuild package, not exact

  ebuild)

    or

- set ACCEPT_KEYWORDS="~<your platform>" and/or /etc/portage/package.unmask

  (and remove /root/.revdep-rebuild.5_order to be evaluated again)

    or

- modify the above emerge command and run it manually

    or

- compile or unmerge unsatisfied packages manually, remove temporary files and

  try again (you can edit package/ebuild list first)

To remove temporary files, please run:

rm /root/.revdep-rebuild*.?_*

```

yona

----------

## firefly

öhm ich glaube du hast xmms-mad nicht sauber deinstalliert.

denn das plugin an sich ist ja noch vorhanden

 *Quote:*   

> broken /usr/lib/xmms/Input/libxmmsmad.so (requires  libxmms.so.1) 

 

EDIT: und falls in /usr/lib/xmms eh nur diese lib vorhanden ist und du xmms-mad deinstalliert hast, dann lösche einfach das komplette /usr/lib/xmms verzeichnis

----------

## Yonathan

stimmt, sehe ich auch grade.. hatte noch eine ecke xmms-* pakete drauf.. habe die alle erstmal runtergeworfen, mal schauen, was sich jetzt ergibt.

----------

## Yonathan

ok... .das klappte schonmal.

die frage ist nun allerdings noch: wie kann ich die restlichen abhängigkeiten auflösen? bekomme immer eine lange liste an dateien, die benötigt werden:

```
randir enotice # revdep-rebuild -p

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... done.

  (/root/.revdep-rebuild.1_files)

Collecting complete LD_LIBRARY_PATH... done.

  (/root/.revdep-rebuild.2_ldpath)

Checking dynamic linking consistency...

  broken /usr/lib/avifile-0.7/divx4.la (requires /usr/lib/libaviplay.la)

  broken /usr/lib/avifile-0.7/divx4.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/divx4.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/divx4.la (requires /-lstdc++)

  broken /usr/lib/avifile-0.7/divx4.la (requires /-lstdc++)

  broken /usr/lib/directfb-0.9.22/inputdrivers/libdirectfb_sdlinput.la (requires /-lstdc++)

  broken /usr/lib/directfb-0.9.22/systems/libdirectfb_sdl.la (requires /-lstdc++)

  broken /usr/lib/libimlib-tiff.la (requires /usr/lib/libgdk_imlib.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkio.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkdeui.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkdesu.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkwalletclient.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkdecore.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libDCOP.la)

  broken /usr/lib/libk3bcore.la (requires /usr/kde/3.4/lib/libkdefx.la)

  broken /usr/lib/xmms/Input/libmpc.la (requires /usr/lib/libmusepack.la)

  broken /usr/lib/xmms/Input/libmpc.la (requires /usr/lib/libxmms.la)

 done.

  (/root/.revdep-rebuild.3_rebuild)

Assigning files to ebuilds... done.

  (/root/.revdep-rebuild.4_ebuilds)

Evaluating package order... done.

  (/root/.revdep-rebuild.5_order)

Dynamic linking on your system is consistent... All done.

```

was kann man dagegen tun?

----------

## ConiKost

Du hast noch KDE 3.4 drauf? Könnte es was damit zu tun haben ?

----------

## Yonathan

nein, habe ich eben nicht mehr.

habe das ganz aktuelle ~x86 kde 3.5

----------

## ConiKost

 *Yonathan wrote:*   

> nein, habe ich eben nicht mehr.
> 
> habe das ganz aktuelle ~x86 kde 3.5

 

Dann emerge mal k3b neu! Dann sollte es gegen die neue 3.5er Libs gelinkt sein!

----------

## schachti

War bei mir auch so, ich habe die alten .la Dateien von KDE 3.4 gelöscht, und dann war Ruhe.

Hast Du vielleicht auch noch das USE flag xmms gesetzt? Dann entfernen und emerge -Du --newuse world durchführen.

----------

## Yonathan

k3b hat in den letzten wochen und monaten ständig ein update erfahren... das ist mindestens schon 6mal neu emerged worden, aber es hat sich nie gegen die neuen bibliotheken gelinkt.

habe die alle mal gelöscht, wurden aber nach dem emerge wieder neu eingerichtet....

xmms habe ich als use-flag überall raus

----------

## amne

Bei den .la-Files handelt es sich um Libtool-Zeugs, das bei fix_libtools_files.sh verändert wird. Da sie geändert wurden (das hat sich meines Wissens nach übrigens mit gcc 4 erledigt) glaubt Portage, dass sie nicht zu einem Paket gehören und lässt sie bei der Deinstallation auf der Platte.

Um zu überprüfen, zu welchem Paket ein File gehört, mach folgendes:

```
emerge app-portage/portage-utils (Falls noch nicht vorhanden)

qfile /usr/lib/avifile-0.7/divx4.la
```

Wenn nichts ausgegeben wird gehört das File zu keinem via Portage installierten Paket und kann gelöscht werden.

----------

## firefly

amne: portage weis schon, zu welchem paket diese dateien gehören. Da sich aber die mtime durch die Änderungen von flix_libtools_files.sh verändert hat, werden diese nicht mit gelöscht beim deinstallieren des pakets, da portage nicht sicher sein kann, ob diese dateien nicht doch noch irgentwie "gebraucht" werden.

Man könnte aber zumindestens by *.la files ne ausnahme machen, das sie auch bei veränderter mtime mit gelöscht werden, wenn die zu der libtool datei gehörenden lib dateien gelöscht wurden.

----------

## amne

 *firefly wrote:*   

> amne: portage weis schon, zu welchem paket diese dateien gehören. Da sich aber die mtime durch die Änderungen von flix_libtools_files.sh verändert hat, werden diese nicht mit gelöscht beim deinstallieren des pakets, da portage nicht sicher sein kann, ob diese dateien nicht doch noch irgentwie "gebraucht" werden.

 

Das hab ich eigentlich mit "Da sie geändert wurden..." gesagt, oder.  :Wink: 

 *firefly wrote:*   

> Man könnte aber zumindestens by *.la files ne ausnahme machen, das sie auch bei veränderter mtime mit gelöscht werden, wenn die zu der libtool datei gehörenden lib dateien gelöscht wurden.

 

Hat sich wie gesagt mit gcc 4(.1?) erledigt, da das in Zukunft nicht mehr notwendig sein wird wenn ich mich nicht täusche.

----------

## firefly

 *amne wrote:*   

> ...glaubt Portage, dass sie nicht zu einem Paket gehören...

 

mir gings eher um diese Aussage.

Nach deiner Aussage, zumindestens habe ich diese so verstanden, würde portage nicht mehr wissen ob die Datei zu einem Paket gehört.  Wenn das stimmen würde, wieso tauchen dann solche Dateien trotzdem in der Ausgabe von emerge auf (mit !mtime als prefix), wenn man ein Paket deinstalliert, bei dem die *.la Dateien durch das fix_libtools_files.sh skript verändert wurden?

----------

## amne

Das ist jetzt vielleicht Interpretationssache.

Richtig, Portage weiss, welche Files zu einem Paket gehören - sowohl die Meldung beim unmerge als auch qfile wären sonst nicht möglich. Wenn sich die mtime gegenüber den gespeicherten Daten geändert hat bleibt jetzt Platz für Interpretationen ob Portage glaubt es gehört nicht zum Paket oder was auch immer - auf jeden Fall wirds nicht entfernt.  :Wink: 

----------

