Je viens de mettre à jour gnome et j'ai plusieurs dépendances de cassées
(non, non, ca n'est pas un troll :) )
lorsque je fais un revdep-rebuild, j'ai une liste énorme de choses qui
ne vont pas ... et tout ce qui est fait c'est réinstaller azureus (le
binaire qui plus est).
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
Stéphan BERNARD
a écrit : > (...) > lorsque je fais un revdep-rebuild, j'ai une liste énorme de choses qui > ne vont pas ... et tout ce qui est fait c'est réinstaller azureus (le > binaire qui plus est). > > Vous me conseillez de faire quoi ? > > merci, polytan > > > le revdep-rebuild : > > Checking dynamic linking consistency... > broken /usr/bin/background-properties-capplet (requires > libart_lgpl.so.2 libgdk_imlib.so.1 libgdk_pixbuf.so.2 libgnome.so.32 > libgnomesupport.so.0 libgnomeui.so.32 libgnorba.so.27 libImlib.so.1) > (...) > broken /usr/lib/python2.4/site-packages/gtk-1.2/gdkpixbufmodule.la > (requires /usr/lib/libgdk_pixbuf.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) > > All prepared. Starting rebuild... > emerge --oneshot =net-p2p/azureus-bin-2.4.0.2 > .......... > Calculating dependencies... done! > > > voila > > polytan
Bonjour,
J'ai eu récemment le même problème, sauf qu'il me proposait à chaque fois de recompiler gcc, (et seulement gcc) alors qu'il y avait une longue liste de "broken" qui n'avait rien à voir avec gcc (du style /usr/lib/avifile entre autres), et seulement deux qui concernaient gcc.
Je me suis amusé à renommer (en ajoutant un .bak) les deux "broken" qui concernaient gcc, puis à recompiler gcc. Et là, miracle, revdep-rebuild ne me proposait plus gcc (mais le reste de la liste des broken était toujours là).
Du coup, j'ai renommé tous les broken de la liste, en supposant qu'ils viennent de vieilles versions de packages mal désinstallés (ça va faire 3 ans que cette gentoo est installée).
J'ai fait cette manip depuis une semaine, et je n'ai eu à déplorer aucun dysfonctionnement, mais peut-être ai-je eu du bol ?
Néanmoins, je suis à peu près certain que cette solution n'est pas des plus élégantes. Un emerge --depclean peut-être ? Je ne suis malheureusement pas très chaud, car malgré son âge, cette machine est encore très utilisée par plusieurs personnes et je n'aimerais pas casser l'install...
-- Stéphan BERNARD
-- mailing list
polytan@gmail.com a écrit :
> (...)
> lorsque je fais un revdep-rebuild, j'ai une liste énorme de choses qui
> ne vont pas ... et tout ce qui est fait c'est réinstaller azureus (le
> binaire qui plus est).
>
> Vous me conseillez de faire quoi ?
>
> merci, polytan
>
>
> le revdep-rebuild :
>
> Checking dynamic linking consistency...
> broken /usr/bin/background-properties-capplet (requires
> libart_lgpl.so.2 libgdk_imlib.so.1 libgdk_pixbuf.so.2 libgnome.so.32
> libgnomesupport.so.0 libgnomeui.so.32 libgnorba.so.27 libImlib.so.1)
> (...)
> broken /usr/lib/python2.4/site-packages/gtk-1.2/gdkpixbufmodule.la
> (requires /usr/lib/libgdk_pixbuf.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)
>
> All prepared. Starting rebuild...
> emerge --oneshot =net-p2p/azureus-bin-2.4.0.2
> ..........
> Calculating dependencies... done!
>
>
> voila
>
> polytan
Bonjour,
J'ai eu récemment le même problème, sauf qu'il me proposait à chaque
fois de recompiler gcc, (et seulement gcc) alors qu'il y avait une
longue liste de "broken" qui n'avait rien à voir avec gcc (du style
/usr/lib/avifile entre autres), et seulement deux qui concernaient gcc.
Je me suis amusé à renommer (en ajoutant un .bak) les deux "broken" qui
concernaient gcc, puis à recompiler gcc. Et là, miracle, revdep-rebuild
ne me proposait plus gcc (mais le reste de la liste des broken était
toujours là).
Du coup, j'ai renommé tous les broken de la liste, en supposant qu'ils
viennent de vieilles versions de packages mal désinstallés (ça va faire
3 ans que cette gentoo est installée).
J'ai fait cette manip depuis une semaine, et je n'ai eu à déplorer aucun
dysfonctionnement, mais peut-être ai-je eu du bol ?
Néanmoins, je suis à peu près certain que cette solution n'est pas des
plus élégantes. Un emerge --depclean peut-être ? Je ne suis
malheureusement pas très chaud, car malgré son âge, cette machine est
encore très utilisée par plusieurs personnes et je n'aimerais pas casser
l'install...
a écrit : > (...) > lorsque je fais un revdep-rebuild, j'ai une liste énorme de choses qui > ne vont pas ... et tout ce qui est fait c'est réinstaller azureus (le > binaire qui plus est). > > Vous me conseillez de faire quoi ? > > merci, polytan > > > le revdep-rebuild : > > Checking dynamic linking consistency... > broken /usr/bin/background-properties-capplet (requires > libart_lgpl.so.2 libgdk_imlib.so.1 libgdk_pixbuf.so.2 libgnome.so.32 > libgnomesupport.so.0 libgnomeui.so.32 libgnorba.so.27 libImlib.so.1) > (...) > broken /usr/lib/python2.4/site-packages/gtk-1.2/gdkpixbufmodule.la > (requires /usr/lib/libgdk_pixbuf.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) > > All prepared. Starting rebuild... > emerge --oneshot =net-p2p/azureus-bin-2.4.0.2 > .......... > Calculating dependencies... done! > > > voila > > polytan
Bonjour,
J'ai eu récemment le même problème, sauf qu'il me proposait à chaque fois de recompiler gcc, (et seulement gcc) alors qu'il y avait une longue liste de "broken" qui n'avait rien à voir avec gcc (du style /usr/lib/avifile entre autres), et seulement deux qui concernaient gcc.
Je me suis amusé à renommer (en ajoutant un .bak) les deux "broken" qui concernaient gcc, puis à recompiler gcc. Et là, miracle, revdep-rebuild ne me proposait plus gcc (mais le reste de la liste des broken était toujours là).
Du coup, j'ai renommé tous les broken de la liste, en supposant qu'ils viennent de vieilles versions de packages mal désinstallés (ça va faire 3 ans que cette gentoo est installée).
J'ai fait cette manip depuis une semaine, et je n'ai eu à déplorer aucun dysfonctionnement, mais peut-être ai-je eu du bol ?
Néanmoins, je suis à peu près certain que cette solution n'est pas des plus élégantes. Un emerge --depclean peut-être ? Je ne suis malheureusement pas très chaud, car malgré son âge, cette machine est encore très utilisée par plusieurs personnes et je n'aimerais pas casser l'install...
-- Stéphan BERNARD
-- mailing list
Thomas de Grenier de Latour
On Mon, 07 Aug 2006 14:25:35 +0200, "" wrote:
lorsque je fais un revdep-rebuild, j'ai une liste énorme de choses qui ne vont pas ... et tout ce qui est fait c'est réinstaller azureus (le binaire qui plus est).
Quand je confronte ta liste de fichiers cassés à mon système, je trouve, en plus d'Azureus (qui est effectivement un binaire éternellement "cassé", que revdep-rebuild s'acharnera à toujours réinstaller), ces paquets ci : - "dev-util/subversion" (évidemment) pour /usr/lib/libsvnjavahl-1.la (seulement avec le USE flag "java" je suppose) - "dev-python/wxpython" (évidemment aussi) pour tous les /usr/lib/python2.4/site-packages/wx-2.4-gtk2-unicode/wxPython/*
Maigre pêche en vérité...
Quelques autres pistes et explications en vrac :
- il est extrêmement fréquent d'avoir des fichiers libtool (.la) orphelins sur un système : c'est parceque le script fix_libtool.sh (ou qlqch comme ça) utilisé lors des upgrades de GCC les modifient ; du coup, ils changent de mtime et md5, et Portage préfère ne plus y toucher lors des désinstallations des paquets qui les avaient introduits. Bref, pour ceux là, rien de suprenant, et tu peux tout simplement les effacer.
- dans un autre genre, il y a aussi "prelink", très à la mode à une époque, qui modifie des binaires et bibliothèques. Si tu l'as un jour lancé sur ton système, ça expliquerait très bien les autres orphelins.
- une majorité de tes fichiers (gnomecc et ses capplets, les machins bonobo, les versions obsolètes des libs gnome & compagnie, etc.) datent de l'époque de Gnome-1.x (ou peut être de vieux 2.x, et encore...). Là aussi je dirai qu'ils ne te manqueront pas trop si tu les vires.
- les plugins Xine 1.1.1 sont probablement remplacés par des équivalents 1.1.2, dans un répertoire homonyme.
- dans le même genre, les trucs perl-5.8.6 ont vraisemblablement des équivalent perl-5.8.7 ou 5.8.8.
- avifile a disparu de Portage il y a longtemps, plus rien ne l'utilise, bref là aussi c'est des orphelins qui trainent.
Finalement, tous ces "fichiers cassés" (sauf celui d'Azureus) me semblent effaçables. Y compris ceux de subversion et wxpython : - pour svn, tu as probablement eu un jour le flag java, et tu ne l'as plus (ou tu n'as carement plus svn, mais on aurait sûrement vu d'autres orphelins) - pour wxpython, il s'agit de la version 2.4, et tu as dû, je suppose, passer complètement à la 2.6 depuis.
Bon, maintenant, la mauvaise nouvelle c'est qu'il reste sûrement plein d'orphelins sur ton système : tu viens seulement d'en détecter qlquns par hasard (ceux qui avaient des liaisons isolubles) en fait... Si tu veux te lancer dans un grand ménage, et bah je dois te prévenir que ça sera un peu fastidieux; mais bon, y'a quand même qlqs astuces pour en partie automatiser, hésite pas à demander.
-- TGL. -- mailing list
On Mon, 07 Aug 2006 14:25:35 +0200,
"polytan@gmail.com" <polytan@gmail.com> wrote:
lorsque je fais un revdep-rebuild, j'ai une liste énorme de choses
qui ne vont pas ... et tout ce qui est fait c'est réinstaller azureus
(le binaire qui plus est).
Quand je confronte ta liste de fichiers cassés à mon système, je
trouve, en plus d'Azureus (qui est effectivement un binaire
éternellement "cassé", que revdep-rebuild s'acharnera à toujours
réinstaller), ces paquets ci :
- "dev-util/subversion" (évidemment) pour /usr/lib/libsvnjavahl-1.la
(seulement avec le USE flag "java" je suppose)
- "dev-python/wxpython" (évidemment aussi) pour tous les
/usr/lib/python2.4/site-packages/wx-2.4-gtk2-unicode/wxPython/*
Maigre pêche en vérité...
Quelques autres pistes et explications en vrac :
- il est extrêmement fréquent d'avoir des fichiers libtool (.la)
orphelins sur un système : c'est parceque le script fix_libtool.sh
(ou qlqch comme ça) utilisé lors des upgrades de GCC les modifient ; du
coup, ils changent de mtime et md5, et Portage préfère ne plus y
toucher lors des désinstallations des paquets qui les avaient
introduits. Bref, pour ceux là, rien de suprenant, et tu peux tout
simplement les effacer.
- dans un autre genre, il y a aussi "prelink", très à la mode à une
époque, qui modifie des binaires et bibliothèques. Si tu l'as un jour
lancé sur ton système, ça expliquerait très bien les autres orphelins.
- une majorité de tes fichiers (gnomecc et ses capplets, les machins
bonobo, les versions obsolètes des libs gnome & compagnie, etc.) datent
de l'époque de Gnome-1.x (ou peut être de vieux 2.x, et encore...). Là
aussi je dirai qu'ils ne te manqueront pas trop si tu les vires.
- les plugins Xine 1.1.1 sont probablement remplacés par des
équivalents 1.1.2, dans un répertoire homonyme.
- dans le même genre, les trucs perl-5.8.6 ont vraisemblablement des
équivalent perl-5.8.7 ou 5.8.8.
- avifile a disparu de Portage il y a longtemps, plus rien ne
l'utilise, bref là aussi c'est des orphelins qui trainent.
Finalement, tous ces "fichiers cassés" (sauf celui d'Azureus) me
semblent effaçables. Y compris ceux de subversion et wxpython :
- pour svn, tu as probablement eu un jour le flag java, et tu ne l'as
plus (ou tu n'as carement plus svn, mais on aurait sûrement vu
d'autres orphelins)
- pour wxpython, il s'agit de la version 2.4, et tu as dû, je suppose,
passer complètement à la 2.6 depuis.
Bon, maintenant, la mauvaise nouvelle c'est qu'il reste sûrement plein
d'orphelins sur ton système : tu viens seulement d'en détecter qlquns
par hasard (ceux qui avaient des liaisons isolubles) en fait... Si tu
veux te lancer dans un grand ménage, et bah je dois te prévenir que ça
sera un peu fastidieux; mais bon, y'a quand même qlqs astuces pour en
partie automatiser, hésite pas à demander.
lorsque je fais un revdep-rebuild, j'ai une liste énorme de choses qui ne vont pas ... et tout ce qui est fait c'est réinstaller azureus (le binaire qui plus est).
Quand je confronte ta liste de fichiers cassés à mon système, je trouve, en plus d'Azureus (qui est effectivement un binaire éternellement "cassé", que revdep-rebuild s'acharnera à toujours réinstaller), ces paquets ci : - "dev-util/subversion" (évidemment) pour /usr/lib/libsvnjavahl-1.la (seulement avec le USE flag "java" je suppose) - "dev-python/wxpython" (évidemment aussi) pour tous les /usr/lib/python2.4/site-packages/wx-2.4-gtk2-unicode/wxPython/*
Maigre pêche en vérité...
Quelques autres pistes et explications en vrac :
- il est extrêmement fréquent d'avoir des fichiers libtool (.la) orphelins sur un système : c'est parceque le script fix_libtool.sh (ou qlqch comme ça) utilisé lors des upgrades de GCC les modifient ; du coup, ils changent de mtime et md5, et Portage préfère ne plus y toucher lors des désinstallations des paquets qui les avaient introduits. Bref, pour ceux là, rien de suprenant, et tu peux tout simplement les effacer.
- dans un autre genre, il y a aussi "prelink", très à la mode à une époque, qui modifie des binaires et bibliothèques. Si tu l'as un jour lancé sur ton système, ça expliquerait très bien les autres orphelins.
- une majorité de tes fichiers (gnomecc et ses capplets, les machins bonobo, les versions obsolètes des libs gnome & compagnie, etc.) datent de l'époque de Gnome-1.x (ou peut être de vieux 2.x, et encore...). Là aussi je dirai qu'ils ne te manqueront pas trop si tu les vires.
- les plugins Xine 1.1.1 sont probablement remplacés par des équivalents 1.1.2, dans un répertoire homonyme.
- dans le même genre, les trucs perl-5.8.6 ont vraisemblablement des équivalent perl-5.8.7 ou 5.8.8.
- avifile a disparu de Portage il y a longtemps, plus rien ne l'utilise, bref là aussi c'est des orphelins qui trainent.
Finalement, tous ces "fichiers cassés" (sauf celui d'Azureus) me semblent effaçables. Y compris ceux de subversion et wxpython : - pour svn, tu as probablement eu un jour le flag java, et tu ne l'as plus (ou tu n'as carement plus svn, mais on aurait sûrement vu d'autres orphelins) - pour wxpython, il s'agit de la version 2.4, et tu as dû, je suppose, passer complètement à la 2.6 depuis.
Bon, maintenant, la mauvaise nouvelle c'est qu'il reste sûrement plein d'orphelins sur ton système : tu viens seulement d'en détecter qlquns par hasard (ceux qui avaient des liaisons isolubles) en fait... Si tu veux te lancer dans un grand ménage, et bah je dois te prévenir que ça sera un peu fastidieux; mais bon, y'a quand même qlqs astuces pour en partie automatiser, hésite pas à demander.
-- TGL. -- mailing list
Thomas de Grenier de Latour
On Mon, 07 Aug 2006 22:57:43 +0200, Fabrice Delliaux wrote:
Peut-être y a t'il moyen de faire la même chose avec azureus-bin.
Quand je confronte ta liste de fichiers cassés à mon système, je trouve, en plus d'Azureus (qui est effectivement un binaire éternellement "cassé", que revdep-rebuild s'acharnera à toujours réinstaller)
Je sais que pour openoffice-bin, il y a un répertoire à masquer en utilisant la variable SEARCH_DIRS_MASK du make.conf, pour éviter d'avoir à le réméerger à chaque revdep-rebuild.
Peut-être y a t'il moyen de faire la même chose avec azureus-bin.
http://gentoo-wiki.com/TIP_Control_revdep-rebuild -- mailing list
Thomas de Grenier de Latour a écrit :
Quand je confronte ta liste de fichiers cassés à mon système, je
trouve, en plus d'Azureus (qui est effectivement un binaire
éternellement "cassé", que revdep-rebuild s'acharnera à toujours
réinstaller)
Je sais que pour openoffice-bin, il y a un répertoire à masquer en
utilisant la variable SEARCH_DIRS_MASK du make.conf, pour éviter d'avoir
à le réméerger à chaque revdep-rebuild.
Peut-être y a t'il moyen de faire la même chose avec azureus-bin.
http://gentoo-wiki.com/TIP_Control_revdep-rebuild
--
gentoo-user-fr@gentoo.org mailing list
Quand je confronte ta liste de fichiers cassés à mon système, je trouve, en plus d'Azureus (qui est effectivement un binaire éternellement "cassé", que revdep-rebuild s'acharnera à toujours réinstaller)
Je sais que pour openoffice-bin, il y a un répertoire à masquer en utilisant la variable SEARCH_DIRS_MASK du make.conf, pour éviter d'avoir à le réméerger à chaque revdep-rebuild.
Peut-être y a t'il moyen de faire la même chose avec azureus-bin.
http://gentoo-wiki.com/TIP_Control_revdep-rebuild -- mailing list
