J'ai une Gentoo qui pour l'instant ne sert à rien d'autre qu'à être
mise à jour régulièrement.
Je viens de constater dans /usr la présence de pas mal de liens
symboliques pointant vers des fichiers qui ont été supprimés à
l'occasion d'une mise à jour (emerge --update) ou d'une suppression
(emerge --unmerge).
Par exemple:
/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so -> libgcc_s.so.1
(je suis passé en GCC-4.1.1)
/usr/lib/openldap/openldap/back_shell-2.2.so.7 -> back_shell-2.2.so.7.0.21
(les seuls versions de bibliothèques qui subsistent dans ce répertoire
sont en 2.3, pourtant il reste tous les liens vers des 2.2 inexistantes)
Ces liens n'appartiennent plus à aucun package:
# equery belongs /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so /usr/lib/openldap/openldap/back_shell-2.2.so.7
[ Searching for file(s) /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so,/usr/lib/openldap/openldap/back_shell-2.2.so.7 in *... ]
#
Y a-t-il une raison pour que le unmerge ait travaillé aussi salement?
Existe-t-il un outil pour supprimer ces liens de façon fiable (en vérifiant
qu'ils n'appartiennent bien à aucun package actuellement installé)?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sébastien Monbrun aka TiChou
Dans le message <news:, *Jérémy JUST* tapota sur f.c.o.l.configuration :
Bonjour,
Je viens de constater dans /usr la présence de pas mal de liens symboliques pointant vers des fichiers qui ont été supprimés à l'occasion d'une mise à jour (emerge --update) ou d'une suppression (emerge --unmerge).
Y a-t-il une raison pour que le unmerge ait travaillé aussi salement?
Je ne vois qu'une et une seule raison à cela.
Certaines applications étant liées directement à une version précise d'une bibliothèque, lorsqu'on met à jour cette bibliothèque vers une autre version, emerge, pour ne pas casser le système, ne supprime alors pas certains fichiers de l'ancienne bibliothèque et indique aussi à la fin de l'installation de la nouvelle bibliothèque de recompiler/re-emerger les paquets des applications liés avec l'ancienne version de la bibliothèque. Pour cela, on est invité à lancer la commande revdep-rebuild --library libfoo.so.x.y.z qui va chercher automatiquement les applications liées sur l'ancienne bibliothèque et qui va ensuite « re-emerger » automatiquement les paquets des applications trouvées. Enfin, une fois la commande revdep-rebuild terminée, on nous demande de supprimer manuellement les fichiers de l'ancienne bibliothèque. Et c'est là que parfois (je dis bien parfois) des liens peuvent subsister. emerge estime peut être qu'il ne doit pas les supprimer quand une application a été lié sur libfoo-0.3 alors que libfoo-0.3 est un lien vers libfoo-0.3.5 et que la nouvelle bibliothèque est libfoo-0.4.1.
Existe-t-il un outil pour supprimer ces liens de façon fiable (en vérifiant qu'ils n'appartiennent bien à aucun package actuellement installé)?
Je n'en connais pas, mais il ne serait pas trop difficile de faire un script qui ferait ça. Sinon, je ne pense pas non plus qu'il y ait un risque de supprimer tous les liens morts, même les liens qui appartiendraient éventuellement à un paquet en place.
-- Sébastien Monbrun aka TiChou
Dans le message <news:20061001143233.723006bb@norbert.jejust.info>,
*Jérémy JUST* tapota sur f.c.o.l.configuration :
Bonjour,
Je viens de constater dans /usr la présence de pas mal de liens
symboliques pointant vers des fichiers qui ont été supprimés à
l'occasion d'une mise à jour (emerge --update) ou d'une suppression
(emerge --unmerge).
Y a-t-il une raison pour que le unmerge ait travaillé aussi salement?
Je ne vois qu'une et une seule raison à cela.
Certaines applications étant liées directement à une version précise d'une
bibliothèque, lorsqu'on met à jour cette bibliothèque vers une autre
version, emerge, pour ne pas casser le système, ne supprime alors pas
certains fichiers de l'ancienne bibliothèque et indique aussi à la fin de
l'installation de la nouvelle bibliothèque de recompiler/re-emerger les
paquets des applications liés avec l'ancienne version de la bibliothèque.
Pour cela, on est invité à lancer la commande revdep-rebuild --library
libfoo.so.x.y.z qui va chercher automatiquement les applications liées sur
l'ancienne bibliothèque et qui va ensuite « re-emerger » automatiquement les
paquets des applications trouvées. Enfin, une fois la commande
revdep-rebuild terminée, on nous demande de supprimer manuellement les
fichiers de l'ancienne bibliothèque. Et c'est là que parfois (je dis bien
parfois) des liens peuvent subsister. emerge estime peut être qu'il ne doit
pas les supprimer quand une application a été lié sur libfoo-0.3 alors que
libfoo-0.3 est un lien vers libfoo-0.3.5 et que la nouvelle bibliothèque est
libfoo-0.4.1.
Existe-t-il un outil pour supprimer ces liens de façon fiable (en
vérifiant qu'ils n'appartiennent bien à aucun package actuellement
installé)?
Je n'en connais pas, mais il ne serait pas trop difficile de faire un script
qui ferait ça. Sinon, je ne pense pas non plus qu'il y ait un risque de
supprimer tous les liens morts, même les liens qui appartiendraient
éventuellement à un paquet en place.
Dans le message <news:, *Jérémy JUST* tapota sur f.c.o.l.configuration :
Bonjour,
Je viens de constater dans /usr la présence de pas mal de liens symboliques pointant vers des fichiers qui ont été supprimés à l'occasion d'une mise à jour (emerge --update) ou d'une suppression (emerge --unmerge).
Y a-t-il une raison pour que le unmerge ait travaillé aussi salement?
Je ne vois qu'une et une seule raison à cela.
Certaines applications étant liées directement à une version précise d'une bibliothèque, lorsqu'on met à jour cette bibliothèque vers une autre version, emerge, pour ne pas casser le système, ne supprime alors pas certains fichiers de l'ancienne bibliothèque et indique aussi à la fin de l'installation de la nouvelle bibliothèque de recompiler/re-emerger les paquets des applications liés avec l'ancienne version de la bibliothèque. Pour cela, on est invité à lancer la commande revdep-rebuild --library libfoo.so.x.y.z qui va chercher automatiquement les applications liées sur l'ancienne bibliothèque et qui va ensuite « re-emerger » automatiquement les paquets des applications trouvées. Enfin, une fois la commande revdep-rebuild terminée, on nous demande de supprimer manuellement les fichiers de l'ancienne bibliothèque. Et c'est là que parfois (je dis bien parfois) des liens peuvent subsister. emerge estime peut être qu'il ne doit pas les supprimer quand une application a été lié sur libfoo-0.3 alors que libfoo-0.3 est un lien vers libfoo-0.3.5 et que la nouvelle bibliothèque est libfoo-0.4.1.
Existe-t-il un outil pour supprimer ces liens de façon fiable (en vérifiant qu'ils n'appartiennent bien à aucun package actuellement installé)?
Je n'en connais pas, mais il ne serait pas trop difficile de faire un script qui ferait ça. Sinon, je ne pense pas non plus qu'il y ait un risque de supprimer tous les liens morts, même les liens qui appartiendraient éventuellement à un paquet en place.
-- Sébastien Monbrun aka TiChou
Jérémy JUST
Le Sun, 1 Oct 2006 15:54:00 +0200,
Je ne vois qu'une et une seule raison à cela.
Certaines applications étant liées directement à une version précise d'une bibliothèque, lorsqu'on met à jour cette bibliothèque vers une autre version, emerge, pour ne pas casser le système, ne supprime alors pas certains fichiers de l'ancienne bibliothèque et indique aussi à la fin de l'installation de la nouvelle bibliothèque de recompiler/re-emerger les paquets des applications liés avec l'ancienne version de la bibliothèque.
Pour GCC, j'ai effectivement fait toutes ces manips, pour passer d'une version à l'autre sans tout casser au milieu. Pour OpenLDAP, je n'ai pas fait ça consciemment.
Sinon, je ne pense pas non plus qu'il y ait un risque de supprimer tous les liens morts, même les liens qui appartiendraient éventuellement à un paquet en place.
Effectivement, au pire, on cassera quelque chose qui était déjà cassé à cause de ce lien mort.
Bon, je vais faire un ménage un peu brutal, puis je vais re-emerger les paquets qui dépendent des bibliothèques concernées. Ça me semble plus sûr.
Merci pour ton explication. Si de tels liens morts réapparaissent fréquemment, j'irai peut-être suggérer chez Gentoo le développement d'un outil pour faire du ménage le plus proprement possible.
-- Jérémy JUST
Le Sun, 1 Oct 2006 15:54:00 +0200,
Je ne vois qu'une et une seule raison à cela.
Certaines applications étant liées directement à une version précise
d'une bibliothèque, lorsqu'on met à jour cette bibliothèque vers une
autre version, emerge, pour ne pas casser le système, ne supprime
alors pas certains fichiers de l'ancienne bibliothèque et indique
aussi à la fin de l'installation de la nouvelle bibliothèque de
recompiler/re-emerger les paquets des applications liés avec
l'ancienne version de la bibliothèque.
Pour GCC, j'ai effectivement fait toutes ces manips, pour passer
d'une version à l'autre sans tout casser au milieu.
Pour OpenLDAP, je n'ai pas fait ça consciemment.
Sinon, je ne pense pas non plus qu'il y ait un risque de supprimer
tous les liens morts, même les liens qui appartiendraient
éventuellement à un paquet en place.
Effectivement, au pire, on cassera quelque chose qui était déjà cassé
à cause de ce lien mort.
Bon, je vais faire un ménage un peu brutal, puis je vais re-emerger
les paquets qui dépendent des bibliothèques concernées. Ça me semble
plus sûr.
Merci pour ton explication.
Si de tels liens morts réapparaissent fréquemment, j'irai peut-être
suggérer chez Gentoo le développement d'un outil pour faire du ménage
le plus proprement possible.
Certaines applications étant liées directement à une version précise d'une bibliothèque, lorsqu'on met à jour cette bibliothèque vers une autre version, emerge, pour ne pas casser le système, ne supprime alors pas certains fichiers de l'ancienne bibliothèque et indique aussi à la fin de l'installation de la nouvelle bibliothèque de recompiler/re-emerger les paquets des applications liés avec l'ancienne version de la bibliothèque.
Pour GCC, j'ai effectivement fait toutes ces manips, pour passer d'une version à l'autre sans tout casser au milieu. Pour OpenLDAP, je n'ai pas fait ça consciemment.
Sinon, je ne pense pas non plus qu'il y ait un risque de supprimer tous les liens morts, même les liens qui appartiendraient éventuellement à un paquet en place.
Effectivement, au pire, on cassera quelque chose qui était déjà cassé à cause de ce lien mort.
Bon, je vais faire un ménage un peu brutal, puis je vais re-emerger les paquets qui dépendent des bibliothèques concernées. Ça me semble plus sûr.
Merci pour ton explication. Si de tels liens morts réapparaissent fréquemment, j'irai peut-être suggérer chez Gentoo le développement d'un outil pour faire du ménage le plus proprement possible.
-- Jérémy JUST
Patator
Jérémy JUST wrote:
Bonjour,
J'ai une Gentoo qui pour l'instant ne sert à rien d'autre qu'à être mise à jour régulièrement.
Je viens de constater dans /usr la présence de pas mal de liens symboliques pointant vers des fichiers qui ont été supprimés à l'occasion d'une mise à jour (emerge --update) ou d'une suppression (emerge --unmerge). Par exemple:
/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so -> libgcc_s.so.1 (je suis passé en GCC-4.1.1)
/usr/lib/openldap/openldap/back_shell-2.2.so.7 -> back_shell-2.2.so.7.0.21 (les seuls versions de bibliothèques qui subsistent dans ce répertoire sont en 2.3, pourtant il reste tous les liens vers des 2.2 inexistantes)
Ces liens n'appartiennent plus à aucun package:
# equery belongs /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so /usr/lib/openldap/openldap/back_shell-2.2.so.7 [ Searching for file(s) /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so,/usr/lib/openldap/openldap/back_shell-2.2.so.7 in *... ] #
Y a-t-il une raison pour que le unmerge ait travaillé aussi salement? Existe-t-il un outil pour supprimer ces liens de façon fiable (en vérifiant qu'ils n'appartiennent bien à aucun package actuellement installé)?
Jérémy JUST wrote:
Bonjour,
J'ai une Gentoo qui pour l'instant ne sert à rien d'autre qu'à être
mise à jour régulièrement.
Je viens de constater dans /usr la présence de pas mal de liens
symboliques pointant vers des fichiers qui ont été supprimés à
l'occasion d'une mise à jour (emerge --update) ou d'une suppression
(emerge --unmerge).
Par exemple:
/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so -> libgcc_s.so.1
(je suis passé en GCC-4.1.1)
/usr/lib/openldap/openldap/back_shell-2.2.so.7 -> back_shell-2.2.so.7.0.21
(les seuls versions de bibliothèques qui subsistent dans ce répertoire
sont en 2.3, pourtant il reste tous les liens vers des 2.2 inexistantes)
Ces liens n'appartiennent plus à aucun package:
# equery belongs /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so /usr/lib/openldap/openldap/back_shell-2.2.so.7
[ Searching for file(s) /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so,/usr/lib/openldap/openldap/back_shell-2.2.so.7 in *... ]
#
Y a-t-il une raison pour que le unmerge ait travaillé aussi salement?
Existe-t-il un outil pour supprimer ces liens de façon fiable (en vérifiant
qu'ils n'appartiennent bien à aucun package actuellement installé)?
J'ai une Gentoo qui pour l'instant ne sert à rien d'autre qu'à être mise à jour régulièrement.
Je viens de constater dans /usr la présence de pas mal de liens symboliques pointant vers des fichiers qui ont été supprimés à l'occasion d'une mise à jour (emerge --update) ou d'une suppression (emerge --unmerge). Par exemple:
/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so -> libgcc_s.so.1 (je suis passé en GCC-4.1.1)
/usr/lib/openldap/openldap/back_shell-2.2.so.7 -> back_shell-2.2.so.7.0.21 (les seuls versions de bibliothèques qui subsistent dans ce répertoire sont en 2.3, pourtant il reste tous les liens vers des 2.2 inexistantes)
Ces liens n'appartiennent plus à aucun package:
# equery belongs /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so /usr/lib/openldap/openldap/back_shell-2.2.so.7 [ Searching for file(s) /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/libgcc_s.so,/usr/lib/openldap/openldap/back_shell-2.2.so.7 in *... ] #
Y a-t-il une raison pour que le unmerge ait travaillé aussi salement? Existe-t-il un outil pour supprimer ces liens de façon fiable (en vérifiant qu'ils n'appartiennent bien à aucun package actuellement installé)?
