24 - Une mise à jour au 19 mars 2011, presque sans problème
Ma dernière mise à jour remontait au 01/01/2011. Je m'attendais au pire, et non !
Après 2,5 mois sans mise à jour, celle du 19 mars 2011 a été conséquente.
Je lance mes traditionnelles commandes :
# emerge --sync
pour voir si portage est à mettre à jour, et ici la mise à jour est nécessaire par un :
# emerge portage
La version de portage passe à 2.1.9.42.
Ensuite, la non moins traditionnelle commande :
# emerge --update --deep world
Mais 'dev-libs/libgcrypt' et 'dev-libs/libgpg-error' demandent l'USE 'static-libs' ce que j'ajoute dans make.conf (et non dans package.use, car je pense que l'USE en question a de grande chance d'être repris par d'autres programmes)
Mise à jour de 150 paquets, avant de s'arrêter sur le N° 84 avec 'x11-libs/cairo-1.10.2-r1 failed' (la version installée est la 1.8.10). Je supprime le paquet sans me poser trop de question puisque je ne m'en sers pas.
J'enchaîne quand même avec :
# emerge --depclean
Mais cette commande me sort des erreurs et me demande de lancer :
# emerge --deep --update --newuse @world
La commande avec @ m'était inconnue. Une lecture du 'man emerge' plus tard, j'apprends que le @ est nécessaire pour que 'world' passé ainsi en argument soit pris en compte !!! Est-ce nouveau ? je n'en sais rien, mais à priori je dirai oui, puisque le 'man emerge' donne des exemples sans le @. Dorénavant je mettrai le @.
Je m'exécute donc, et c'est parti pour une compilation de 134 paquets qui se passe sans problème.
A l'emerge --depclean suivant, j'ai cependant :
dependencies could not be completely resolved an dev-lang/perl-5.8.8 pulled in by virtual/perl-MIME-BASE64-3.07
or dev-lang/perl-5.12.2-r6 est installé ainsi que virtual/perl-MIME-BASE64-3.07 au lieu de la -3.0.8. Je résous cela par un :
# emerge --update --deep perl-MIME-Base64 # emerge --depcleanUn etc-update plus tard, il me reste à personnaliser quelques fichiers de configuration suite aux modifications apportées. Ainsi :
- Le 'etc-update.conf' change : la ligne avec diff-command="colordiff ..." devient diff-command="diff ..." du coup les changements n'apparaissent plus en couleur, ce que je trouvais pourtant bien pratique !!
Après lecture du man colordiff, ma diff_command devient :
diff_command="colordiff -uN %file1 %file2 | less -R "
- Le bashrc (/etc/bash/bashrc) m'a fait craindre également des modifications sur la coloration syntaxique (un \\007 devient un \033\\) mais je n'ai pas vu d'impact pour mon usage. Et j'avoue que je n'y comprends pas grand chose dans le script.
Et enfin, quand j'ai relu le summary.log (/var/log/portage/elog/summary.log) j'ai vu que pour mettre à jour les modules de Metasploit (logiciel que vous n'avez pas forcément installé), il me fallait lancer la commande suivante :
# cd /usr/lib/metasploit && svn update
Tout cela pour dire qu'il est toujours intéressant de relire le summary.log, pour vérifier que l'on a rien oublié.