Note préliminaire: du bon usage de revdep-rebuild

revdep-rebuild est un utilitaire bien pratique: il retrouve dans les binaires les bibliothèques dynamiques (.so) référencées comme inexistantes.

Il propose ensuite de reconstruire les paquets contenants les binaires concernés.

C'est une bonne idée, mais le seul inconvénient est que revdep-rebuild va reconstruire un ou plusieurs paquets en se fondant sur le numéro de version trouvé dans le binaire. La plupart du temps, il vaut mieux arrêter revdep-rebuild dès qu'il a fini sa liste de paquets à reconstruire, et faire le emerge à la main.

Ceci vous garantira les dernières bibliothèques, ce qui est mieux (la plupart du temps) que de conserver un système à moitié à jour.


Les symptômes d'une Gentoo bancale

Ils sont apparus lors d'une mise à jour de portage.


jseb ~ # emerge -va portage

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

Calculating dependencies... done!

[ebuild     U ] sys-apps/sandbox-1.2.18.1-r2 [1.2.17] 232 kB
[ebuild     U ] dev-python/pycrypto-2.0.1-r6 [2.0.1-r5] USE="-bindist -gmp -test" 151 kB
[ebuild     U ] sys-apps/portage-2.1.4.4 [2.1.2.2] USE="-build -doc -epydoc (-selinux)" LINGUAS="-pl" 368 kB
*** Portage will stop merging at this point and reload itself,
    then resume the merge.
[ebuild     U ] app-shells/bash-3.2_p33 [3.1_p17] USE="nls -afs -bashlogger -plugins% -vanilla" 2,564 kB
[blocks B     ] <sys-apps/portage-2.1.4_rc1 (is blocking app-shells/bash-3.2_p33)

Total: 4 packages (4 upgrades, 1 block), Size of downloads: 3,313 kB

!!! Error: The above package list contains packages which cannot be installed
!!!        at the same time on the same system.

For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

La ligne importante est celle-ci:

[blocks B ] <sys-apps/portage-2.1.4_rc1 (is blocking app-shells/bash-3.2_p33)


Ce qui signifie que la mise à jour de Portage est bloquée par la version de Bash que l'on devrait installer (ou qui est déja installée). Et si on tente de mettre à jour Bash, on obtient ceci:

[ebuild     U ] app-shells/bash-3.2_p33 [3.1_p17] USE="nls -afs -bashlogger -plugins% -vanilla" 2,564 kB
[blocks B     ] <sys-apps/portage-2.1.4_rc1 (is blocking app-shells/bash-3.2_p33)


Nous sommes bien dans le cas de A qui bloque B qui bloque A.


Ce qu'il ne faut surtout pas faire

Il ne faut pas tenter de désinstaller Bash avec emerge -C.

Vous risquez de perdre votre unique shell, ce qui pourrait avoir de grave conséquences (dans un cas comme celui-ci, seule possibilité: compiler un paquet binaire Gentoo sur un autre système, et installer celui-ci sur votre système. Ensuite, emerger Bash depuis votre système immédiatement).
Bien entendu, si vous avez plusieurs shells (zsh, tcsh..), ce que j'ai écrit au dessus ne s'applique pas, mais ce n'est pas une raison pour le faire. Dans le pire des cas, vous aurez toujours bb (BusyBox) en guise de shell de secours, mais il n'est pas suffisant pour lancer emerge.


Résolution

Il faut tenter de faire une mise à jour progressive.

emerge -va '<bash-2.3_p33'

va installer la version précédente de Bash.

Ensuite, il faut installer la version actuelle de Portage (celle qui bloquait précédemment).

emerge -va portage

Une fois Portage mis à jour, il ne reste qu'à installer le dernier ebuild de Bash

emerge -va bash

Et le système est à nouveau à niveau (pour cette partie du moins).


Alors ça y est, ça marche ?

D'autres cas peuvent nécessiter une mise à jour progressive du système, pour isoler les paquets qui posent problème dans leurs dépendances circulaires.

emerge -vau system renvoie ceci:

[blocks B     ] sys-apps/mktemp (is blocking sys-apps/coreutils-6.10-r2)
[blocks B     ] >=sys-apps/coreutils-6.10 (is blocking sys-apps/mktemp-1.5)

Nous ne sommes pas dans le même cas que précédemment, car mktemp n'est disponible que dans une seule version. La montée de version progressive n'est donc pas possible dans ce cas.


jseb | # eix mktemp
[I] sys-apps/mktemp
     Available versions:  1.5
     Installed versions:  1.5(02:51:44 20.04.2007)
     Homepage:            http://www.mktemp.org/
     Description:         allow safe temporary file creation from shell scripts.

Par contre, le descriptif nous informe qu'enlever mktemp le temps d'upgrader les coreutils ne devrait pas poser de stabilité du système.

Attention faire l'inverse (enlever les coreutils) serait une très mauvaise idée.


Nous allons donc enlever mktemp : emerge -C mktemp

Puis tenter d'installer les coreutils. Enfer !

 
jseb ~ # emerge -va coreutils

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

Calculating dependencies... done!
[ebuild  N    ] dev-perl/Locale-gettext-1.05  8 kB
[ebuild  N    ] app-arch/lzma-utils-4.32.6  USE="-nocxx" 468 kB
[ebuild  N    ] sys-apps/help2man-1.36.4  USE="nls" 84 kB
[ebuild     U ] sys-devel/automake-1.10.1 [1.10] 897 kB
[ebuild     U ] sys-apps/coreutils-6.10-r2 [6.4] USE="acl nls (-selinux) -static -vanilla% -xattr%" 3,692 kB
[blocks B     ] <sys-apps/util-linux-2.13 (is blocking sys-apps/coreutils-6.10-r2)


Ce n'est pas grave. Commençons par emerger la dernière version des util-linux : emerge -va util-linux

Ensuite, on peut enfin emerger les coreutils : emerge -va coreutils

On ne peut toujours pas réemerger mktemp. Pas d'inquiétude, c'est parce qu'il a été intégré dans un autre paquet, qui se trouve être ... coreutils, justement.

epm -qf `which mktemp` donne : coreutils-6.10-r2

ou encore (commande équivalente)

equery b mktemp : donne le nom des packages contenants le fichier mktemp


Installer un ebuild plus récent que celui bloquant

Cette fois, le problème est résolu en montant de version directement.

jseb ~ # emerge -vp wxGTK

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

Calculating dependencies... done!
[ebuild  N    ] app-admin/eselect-wxwidgets-0.8  0 kB 
[ebuild  NS   ] x11-libs/wxGTK-2.8.7.1-r1  USE="X opengl -debug -doc -gnome -gstreamer -odbc -pch -sdl" 25,745 kB 
[blocks B     ] <=x11-libs/wxGTK-2.6.4.0-r2 (is blocking app-admin/eselect-wxwidgets-0.8)


eselect-wxwidgets n'est disponible que dans une version.

Installer une version inférieure de wxGTK n'a mené à rien.

Seule solution: tenter de monter de version pour wxGTK.

jseb ~ # eix wxGTK
[U] x11-libs/wxGTK
     Available versions:  
        (2.6)   2.6.4.0-r1 2.6.4.0-r3 ~2.6.4.0-r4
        (2.8)   2.8.7.1-r1 ~2.8.7.1-r2 ~2.8.8.0


On installe la plus récente stable : emerge -va '=wxGTK-2.6.4.0-r3'

C'est bon, ça maaaaarche.


Retrouver une dépendance enfouie.

Je gardais le meilleur pour la fin.

Certaines dépendances sont tellement enfouies qu'on ne les retrouve pas directement.

Un exemple : tous vos programmes utilisant GTK cessent de fonctionner et réclament la bibliothèque partagée libexpat.so.0.

Une rapide recherche nous renseigne: cette bibliothèque partagée a été renommée. Horreur. Va-t-il falloir tout recompiler ?

Non, car c'est GTK+ qui est concerné.

Bon, alors on recompile GTK+, c'est bien ça ?

Non (du moins, pas tout de suite), car la dépendance à la libexpat n'est pas directe, et viens d'une autre bibliothèque à laquelle est lié GTK+.

Les gens qui connaissent un peu la hiérarchie de cette bibliothèque vont recompiler de façon préventive pango et glib (à ne pas confondre avec la glibc qui est la bibliothèque des fonctions systèmes).

Perdu, le coupable était poppler, une obscure bibliothèque chargée du rendering pdf.

Bon. J'avoue que j'ai triché, et qu'on me l'a dit. Mais vous pouvez être confronté à un cas où vous vous retrouverez seul au monde avec votre dépendance enfouie.

Comment savoir dans un cas tel que celui-ci, ou au moins avoir une liste de suspects ?

Il faut retrouver tous les paquets en dépendance de GTK+ : emerge -Dp gtk+

ensuite, récupérer la liste des bibliothèques avec un equery f paquet

Ensuite, rechercher expat dans la liste des bibliothèques dynamiques obtenues précédemment.

ldd /usr/lib64/libpoppler.so.2.0.0 | grep expat
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f8867cb7000)

L'exemple ci-dessus est donné à titre indicatif. Il faut bien sûr mieux faire un script, même pour les gens patient (tout le monde en a marre un jour, sauf les cliqueurs sous MS-Windows).

Gagné, c'était bien poppler. Mais il y aurait pu en avoir d'autres.

Donc dans ce cas, il faudra recompiler poppler, puis gtk+. Et toutes vos applications refonctionneront comme au premier jour. C'est beau, snif.


Craaaaaac !

Hé bin voila m'dame Gentoo, j'vous z'avais bien dit qu'c'était pas grand chose!

Et n'hésitez pas à revenir me voir si vous z'avez d'nouveau mal au dos.

Le mieux est quand même d'avoir un système à jour, en exécutant cette commande régulièrement (disons une ou deux fois par mois) :

emerge -vau system

Ceci devrait vous prémunir des blocages les plus gênants, et d'une façon générale, votre Gentoo ne s'en portera pas plus mal.

Attention, pour l'emerge général system, il vaut mieux rester à proximité, au cas où il serait nécessaire d'arrêter le process pour faire un revdep-rebuild.

Remerciements à Frédéric qui m'a passé un binaire de Bash le temps de rétablir la situation ;)