j'en peux plus, =E7a fait deux jours que je suis sur ce probl=E8me, et en p=
lus,=20
c'est m=EAme pas pour moi !!
J'administre plusieurs Gentoo =E0 distance pour divers usage.=20
Sur l'une d'entre-elles, j'ai le probl=E8me suivant :
le lancement de kopete indique qu'il ne trouve pas la librairie
/usr/lib/kde3/kcm_kopete_accountconfig.so=20
Effectivement, ce fichier n'existe pas.
Comme souvent avec les outils KDE, cette biblioth=E8que n'est pas li=E9e de=
fa=E7on=20
standard =E0 kopete : 'ldd $(which kopete)' ne liste pas=20
kcm_kopete_accountconfig.so dans ses d=E9pendances. J'imagine que c'est un=
=20
'dlopen()' qui est utilis=E9. Bref.
L=E0, je fais un 'ls /usr/lib/kde3', et je vois entre-autres un=20
'/usr/lib/kde3/kcm_kopete_accountconfig.la'. Premi=E8re question qu'est ce =
que=20
c'est que ce truc ? Un '.la' ?
J'avais jamais vu. Les premi=E8res lignes de ce fichier indique que =E7a pe=
rmet de=20
lier...
Mais surtout, surtout, je cherche =E0 savoir qui a install=E9 ce fichier (e=
t =E0=20
oubli=E9 au passage le .so...) donc :
Et l=E0 : aucune r=E9ponse !! Aucun ebuild n'a install=E9 ce fichier.
J'ai d=E9j=E0 fait des emerge unmerge kdenetwork ; emerge kdenetwork, rien =
=E0=20
faire.
J'y comprends rien ! D'autant que sur les autres b=E9canes, kopete fonction=
ne=20
sans ce fichier, du moins pas =E0 cet endroit (ils sont=20
dans /usr/kde/3.x/lib/*, pas dans /usr/lib/kde3). Alors si vous avez une=20
id=E9e, je suis preneur, parceque c'est le genre de probl=E8me que je ne su=
pporte=20
pas sur la gentoo, et il y en a beaucoup !=20
En particulier, il est quasi impossible de faire des emerge -uD world dans =
une=20
crontab, principalement =E0 cause des messages d'erreurs (manipulations =E0=
=20
r=E9aliser au fur et =E0 mesure), ou des probl=E8mes de slots... (kde-3.1, =
3.2,=20
3.3, bient=F4t, il y en aura 20...).
J'adore la gentoo, mais il me semble qu'il manque des m=E9thodes de tests p=
our=20
assurer la fiabilit=E9 des upgrades !
Bref, je suis un peu d=E9sesp=E9r=E9 ! 2 jours... A l'aide !=20
En particulier, il est quasi impossible de faire des emerge -uD world dans une crontab
Et pas du tout prudent de toute mannière.
Un #emerge -uD world# qui se passe sans problème peut très bien mettre à jour une librairie qui casse les paquets qui en dépendent (par exemple la mise à jour d'openssl dont dépend ssh : délicat sur un serveur distant...) Et nécéssiter des actions précises (par exemple revdep-rebuild qqchose.so et redémarrage d'sshd, le tout dans la même session ssh, autrement...). Et oui, il faut *toujours* lire les messages à la fin des ebuilds ;)
Pour autant que je sache, il n'existe pas de système dont la mise à jour soit *sans risque* (et je ne vois pas comment il pourrait en être autrement), y compris Windows via WindowsUpdate. Et j'imagine que c'est la raison pour laquelle emerge n'est pas déstiné à être executé en aveugle en crontab.
.02 ¤
-- Yoann Pannier
-- mailing list
Pierre Vignéras wrote:
En particulier, il est quasi impossible de faire des emerge -uD world dans une
crontab
Et pas du tout prudent de toute mannière.
Un #emerge -uD world# qui se passe sans problème peut très bien mettre à
jour une librairie qui casse les paquets qui en dépendent (par exemple
la mise à jour d'openssl dont dépend ssh : délicat sur un serveur
distant...) Et nécéssiter des actions précises (par exemple
revdep-rebuild qqchose.so et redémarrage d'sshd, le tout dans la même
session ssh, autrement...). Et oui, il faut *toujours* lire les messages
à la fin des ebuilds ;)
Pour autant que je sache, il n'existe pas de système dont la mise à jour
soit *sans risque* (et je ne vois pas comment il pourrait en être
autrement), y compris Windows via WindowsUpdate. Et j'imagine que c'est
la raison pour laquelle emerge n'est pas déstiné à être executé en
aveugle en crontab.
En particulier, il est quasi impossible de faire des emerge -uD world dans une crontab
Et pas du tout prudent de toute mannière.
Un #emerge -uD world# qui se passe sans problème peut très bien mettre à jour une librairie qui casse les paquets qui en dépendent (par exemple la mise à jour d'openssl dont dépend ssh : délicat sur un serveur distant...) Et nécéssiter des actions précises (par exemple revdep-rebuild qqchose.so et redémarrage d'sshd, le tout dans la même session ssh, autrement...). Et oui, il faut *toujours* lire les messages à la fin des ebuilds ;)
Pour autant que je sache, il n'existe pas de système dont la mise à jour soit *sans risque* (et je ne vois pas comment il pourrait en être autrement), y compris Windows via WindowsUpdate. Et j'imagine que c'est la raison pour laquelle emerge n'est pas déstiné à être executé en aveugle en crontab.
.02 ¤
-- Yoann Pannier
-- mailing list
Yoann Pannier
Pierre Vignéras wrote:
le lancement de kopete indique qu'il ne trouve pas la librairie /usr/lib/kde3/kcm_kopete_accountconfig.so
bugs.gentoo.org ? ALL kopete
par exemple : http://bugs.gentoo.org/show_bug.cgi?idA568
-- Yoann Pannier
-- mailing list
Pierre Vignéras wrote:
le lancement de kopete indique qu'il ne trouve pas la librairie
/usr/lib/kde3/kcm_kopete_accountconfig.so
bugs.gentoo.org ? ALL kopete
par exemple : http://bugs.gentoo.org/show_bug.cgi?idA568
le lancement de kopete indique qu'il ne trouve pas la librairie /usr/lib/kde3/kcm_kopete_accountconfig.so
bugs.gentoo.org ? ALL kopete
par exemple : http://bugs.gentoo.org/show_bug.cgi?idA568
-- Yoann Pannier
-- mailing list
Pierre Vignéras
Le Mardi 01 Février 2005 14:02, Yoann Pannier a écrit :
Pierre Vignéras wrote: > En particulier, il est quasi impossible de faire des emerge -uD world > dans une crontab
Et pas du tout prudent de toute mannière.
Un #emerge -uD world# qui se passe sans problème peut très bien mettr e à jour une librairie qui casse les paquets qui en dépendent (par exemple la mise à jour d'openssl dont dépend ssh : délicat sur un serveur distant...) Et nécéssiter des actions précises (par exemple revdep-rebuild qqchose.so et redémarrage d'sshd, le tout dans la même session ssh, autrement...). Et oui, il faut *toujours* lire les messages à la fin des ebuilds ;)
En effet, mais c'est pas facile quand il y a n ebuilds, avec n >> 0 !!
Par exemple, une nouvelle version de KDE est sortie, demandée par les utilisateurs. Il est fort probable que l'upgrade affecte aussi des bibliothèques partagées qui peuvent corrompre un autre outil (openssl justement !). Alors à moins de ne pas utiliser l'option -D, ce que je ne fais jamais, ce problème arrive de toute façon, world ou pas !!
Pour autant que je sache, il n'existe pas de système dont la mise à j our soit *sans risque* (et je ne vois pas comment il pourrait en être autrement), y compris Windows via WindowsUpdate. Et j'imagine que c'est la raison pour laquelle emerge n'est pas déstiné à être executé en aveugle en crontab.
J'ai du mal à comprendre pourquoi un certain nombre d'upgrade ne peuvent pas être réalisées *sans risque* de toute façon !! Le revdep-rebuild de vrait être intégré à emerge, si ne pas l'exécuter est un risque potentiel.
Mais, je trouve qu'un certain nombre d'outils ne sont pas encore assez mature : revdep-rebuild me sort des trucs abracadabrantestque (par exemple de remerger le jdk, puis une fois effectué, de remerger le jdk, puis, ...) ! Le genre de choses qui mériterait des outils de tests adaptés.
L'utilisation systématique de tests devrait faire partie de tout dévelo ppement logiciel, en particulier lorsqu'il est communautaire. Je n'ai pas l'impression que ce soit le cas sur la gentoo. Le passage d'un ebuild de la branche instable (~x86) à stable (x86) se faisant un peu au petit bonheur la chance.
-- Pierre Vignéras
-- mailing list
Le Mardi 01 Février 2005 14:02, Yoann Pannier a écrit :
Pierre Vignéras wrote:
> En particulier, il est quasi impossible de faire des emerge -uD world
> dans une crontab
Et pas du tout prudent de toute mannière.
Un #emerge -uD world# qui se passe sans problème peut très bien mettr e à
jour une librairie qui casse les paquets qui en dépendent (par exemple
la mise à jour d'openssl dont dépend ssh : délicat sur un serveur
distant...) Et nécéssiter des actions précises (par exemple
revdep-rebuild qqchose.so et redémarrage d'sshd, le tout dans la même
session ssh, autrement...). Et oui, il faut *toujours* lire les messages
à la fin des ebuilds ;)
En effet, mais c'est pas facile quand il y a n ebuilds, avec n >> 0 !!
Par exemple, une nouvelle version de KDE est sortie, demandée par les
utilisateurs. Il est fort probable que l'upgrade affecte aussi des
bibliothèques partagées qui peuvent corrompre un autre outil (openssl
justement !). Alors à moins de ne pas utiliser l'option -D, ce que je ne fais
jamais, ce problème arrive de toute façon, world ou pas !!
Pour autant que je sache, il n'existe pas de système dont la mise à j our
soit *sans risque* (et je ne vois pas comment il pourrait en être
autrement), y compris Windows via WindowsUpdate. Et j'imagine que c'est
la raison pour laquelle emerge n'est pas déstiné à être executé en
aveugle en crontab.
J'ai du mal à comprendre pourquoi un certain nombre d'upgrade ne peuvent pas
être réalisées *sans risque* de toute façon !! Le revdep-rebuild de vrait être
intégré à emerge, si ne pas l'exécuter est un risque potentiel.
Mais, je trouve qu'un certain nombre d'outils ne sont pas encore assez
mature : revdep-rebuild me sort des trucs abracadabrantestque (par exemple de
remerger le jdk, puis une fois effectué, de remerger le jdk, puis, ...) ! Le
genre de choses qui mériterait des outils de tests adaptés.
L'utilisation systématique de tests devrait faire partie de tout dévelo ppement
logiciel, en particulier lorsqu'il est communautaire. Je n'ai pas
l'impression que ce soit le cas sur la gentoo. Le passage d'un ebuild de la
branche instable (~x86) à stable (x86) se faisant un peu au petit bonheur la
chance.
Le Mardi 01 Février 2005 14:02, Yoann Pannier a écrit :
Pierre Vignéras wrote: > En particulier, il est quasi impossible de faire des emerge -uD world > dans une crontab
Et pas du tout prudent de toute mannière.
Un #emerge -uD world# qui se passe sans problème peut très bien mettr e à jour une librairie qui casse les paquets qui en dépendent (par exemple la mise à jour d'openssl dont dépend ssh : délicat sur un serveur distant...) Et nécéssiter des actions précises (par exemple revdep-rebuild qqchose.so et redémarrage d'sshd, le tout dans la même session ssh, autrement...). Et oui, il faut *toujours* lire les messages à la fin des ebuilds ;)
En effet, mais c'est pas facile quand il y a n ebuilds, avec n >> 0 !!
Par exemple, une nouvelle version de KDE est sortie, demandée par les utilisateurs. Il est fort probable que l'upgrade affecte aussi des bibliothèques partagées qui peuvent corrompre un autre outil (openssl justement !). Alors à moins de ne pas utiliser l'option -D, ce que je ne fais jamais, ce problème arrive de toute façon, world ou pas !!
Pour autant que je sache, il n'existe pas de système dont la mise à j our soit *sans risque* (et je ne vois pas comment il pourrait en être autrement), y compris Windows via WindowsUpdate. Et j'imagine que c'est la raison pour laquelle emerge n'est pas déstiné à être executé en aveugle en crontab.
J'ai du mal à comprendre pourquoi un certain nombre d'upgrade ne peuvent pas être réalisées *sans risque* de toute façon !! Le revdep-rebuild de vrait être intégré à emerge, si ne pas l'exécuter est un risque potentiel.
Mais, je trouve qu'un certain nombre d'outils ne sont pas encore assez mature : revdep-rebuild me sort des trucs abracadabrantestque (par exemple de remerger le jdk, puis une fois effectué, de remerger le jdk, puis, ...) ! Le genre de choses qui mériterait des outils de tests adaptés.
L'utilisation systématique de tests devrait faire partie de tout dévelo ppement logiciel, en particulier lorsqu'il est communautaire. Je n'ai pas l'impression que ce soit le cas sur la gentoo. Le passage d'un ebuild de la branche instable (~x86) à stable (x86) se faisant un peu au petit bonheur la chance.
-- Pierre Vignéras
-- mailing list
Pierre Vignéras
Le Mardi 01 Février 2005 14:11, Yoann Pannier a écrit :
Pierre Vignéras wrote: > le lancement de kopete indique qu'il ne trouve pas la librairie > /usr/lib/kde3/kcm_kopete_accountconfig.so
bugs.gentoo.org ? ALL kopete
par exemple : http://bugs.gentoo.org/show_bug.cgi?idA568
HARGG !! Mea Culpa !! Et merci beaucoup !
Mais pourquoi n'y ais-je pas pensé plutôt ? Peut-être que j'ai eu tro p confiance en Google (qui ne me trouvait rien)...
Pourtant, je poste moi-même des bugs !! Incroyable et merci encore !!
-- Pierre Vignéras
-- mailing list
Le Mardi 01 Février 2005 14:11, Yoann Pannier a écrit :
Pierre Vignéras wrote:
> le lancement de kopete indique qu'il ne trouve pas la librairie
> /usr/lib/kde3/kcm_kopete_accountconfig.so
bugs.gentoo.org ? ALL kopete
par exemple : http://bugs.gentoo.org/show_bug.cgi?id=41568
HARGG !! Mea Culpa !! Et merci beaucoup !
Mais pourquoi n'y ais-je pas pensé plutôt ? Peut-être que j'ai eu tro p
confiance en Google (qui ne me trouvait rien)...
Pourtant, je poste moi-même des bugs !! Incroyable et merci encore !!
Le Mardi 01 Février 2005 14:11, Yoann Pannier a écrit :
Pierre Vignéras wrote: > le lancement de kopete indique qu'il ne trouve pas la librairie > /usr/lib/kde3/kcm_kopete_accountconfig.so
bugs.gentoo.org ? ALL kopete
par exemple : http://bugs.gentoo.org/show_bug.cgi?idA568
HARGG !! Mea Culpa !! Et merci beaucoup !
Mais pourquoi n'y ais-je pas pensé plutôt ? Peut-être que j'ai eu tro p confiance en Google (qui ne me trouvait rien)...
Pourtant, je poste moi-même des bugs !! Incroyable et merci encore !!
-- Pierre Vignéras
-- mailing list
Yoann Pannier
Pierre Vignéras wrote:
Mais, je trouve qu'un certain nombre d'outils ne sont pas encore assez mature : revdep-rebuild me sort des trucs abracadabrantestque (par exemple de remerger le jdk, puis une fois effectué, de remerger le jdk, puis, ...) ! Le genre de choses qui mériterait des outils de tests adaptés.
Pour le sun-jdk, s'il s'agit d'une machine sans serveur X, c'est normal que revdep-rebuild veuille le ré-installer. Le jdk inclus AWT qui a besoin d'X mais comme X n'est pas une dépendance du jdk (heureusement!), la ré-installation ne change rien.
C'est le problème des ebuilds binaires, et on peut avoir la même chose pour d'autres comme openoffice-bin ou firefox-bin (quand on est pas sous gnome par exemple je crois). Et ça se complique avec des binaires hors portage (genre oracle).
Je ne dis pas que ça fait propre ni que c'est bien comme ça, mais là revdep-rebuild fait exactement ce qu'on lui demande : proposer la réinstallation des paquets à qui il manque des dépendances à l'exécution (enfin des .so quoi).
-- Yoann Pannier
-- mailing list
Pierre Vignéras wrote:
Mais, je trouve qu'un certain nombre d'outils ne sont pas encore assez
mature : revdep-rebuild me sort des trucs abracadabrantestque (par exemple de
remerger le jdk, puis une fois effectué, de remerger le jdk, puis, ...) ! Le
genre de choses qui mériterait des outils de tests adaptés.
Pour le sun-jdk, s'il s'agit d'une machine sans serveur X, c'est normal
que revdep-rebuild veuille le ré-installer. Le jdk inclus AWT qui a
besoin d'X mais comme X n'est pas une dépendance du jdk (heureusement!),
la ré-installation ne change rien.
C'est le problème des ebuilds binaires, et on peut avoir la même chose
pour d'autres comme openoffice-bin ou firefox-bin (quand on est pas sous
gnome par exemple je crois). Et ça se complique avec des binaires hors
portage (genre oracle).
Je ne dis pas que ça fait propre ni que c'est bien comme ça, mais là
revdep-rebuild fait exactement ce qu'on lui demande : proposer la
réinstallation des paquets à qui il manque des dépendances à l'exécution
(enfin des .so quoi).
Mais, je trouve qu'un certain nombre d'outils ne sont pas encore assez mature : revdep-rebuild me sort des trucs abracadabrantestque (par exemple de remerger le jdk, puis une fois effectué, de remerger le jdk, puis, ...) ! Le genre de choses qui mériterait des outils de tests adaptés.
Pour le sun-jdk, s'il s'agit d'une machine sans serveur X, c'est normal que revdep-rebuild veuille le ré-installer. Le jdk inclus AWT qui a besoin d'X mais comme X n'est pas une dépendance du jdk (heureusement!), la ré-installation ne change rien.
C'est le problème des ebuilds binaires, et on peut avoir la même chose pour d'autres comme openoffice-bin ou firefox-bin (quand on est pas sous gnome par exemple je crois). Et ça se complique avec des binaires hors portage (genre oracle).
Je ne dis pas que ça fait propre ni que c'est bien comme ça, mais là revdep-rebuild fait exactement ce qu'on lui demande : proposer la réinstallation des paquets à qui il manque des dépendances à l'exécution (enfin des .so quoi).
-- Yoann Pannier
-- mailing list
Christophe Garault
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Pierre Vignéras a écrit :
| J'ai du mal à comprendre pourquoi un certain nombre d'upgrade ne | peuvent pas être réalisées *sans risque* de toute façon !!
Les fichiers de conf à éditer manuellement? Modification des templates, redémarrage des services, modification des chemins... A dire vrai la liste doit être longue.
- -- Christophe Garault
ps: est-ce toi qui a fait une thèse sur les agents mobiles? Si oui chapeau bas, c'est exactement ce dont je rêvais avant l'avènement des serveurs d'applis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
| J'ai du mal à comprendre pourquoi un certain nombre d'upgrade ne
| peuvent pas être réalisées *sans risque* de toute façon !!
Les fichiers de conf à éditer manuellement? Modification des
templates, redémarrage des services, modification des chemins...
A dire vrai la liste doit être longue.
- --
Christophe Garault
ps: est-ce toi qui a fait une thèse sur les agents mobiles? Si oui
chapeau bas, c'est exactement ce dont je rêvais avant l'avènement des
serveurs d'applis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
| J'ai du mal à comprendre pourquoi un certain nombre d'upgrade ne | peuvent pas être réalisées *sans risque* de toute façon !!
Les fichiers de conf à éditer manuellement? Modification des templates, redémarrage des services, modification des chemins... A dire vrai la liste doit être longue.
- -- Christophe Garault
ps: est-ce toi qui a fait une thèse sur les agents mobiles? Si oui chapeau bas, c'est exactement ce dont je rêvais avant l'avènement des serveurs d'applis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
On Tue, 1 Feb 2005 15:13:28 +0100 Pierre Vignéras wrote:
En effet, mais c'est pas facile quand il y a n ebuilds, avec n >> 0 !!
Tu peux essayer ça: http://tdegreni.free.fr/gentoo/portlog-info (ça nécessite d'avoir un répertoire PORTLOG_DIR dans make.conf, pour activer les logs détaillés par ebuild)
-- TGL.
-- mailing list
On Tue, 1 Feb 2005 15:13:28 +0100
Pierre Vignéras <eipi@nerim.net> wrote:
En effet, mais c'est pas facile quand il y a n ebuilds, avec n
>> 0 !!
Tu peux essayer ça:
http://tdegreni.free.fr/gentoo/portlog-info
(ça nécessite d'avoir un répertoire PORTLOG_DIR dans make.conf,
pour activer les logs détaillés par ebuild)
On Tue, 1 Feb 2005 15:13:28 +0100 Pierre Vignéras wrote:
En effet, mais c'est pas facile quand il y a n ebuilds, avec n >> 0 !!
Tu peux essayer ça: http://tdegreni.free.fr/gentoo/portlog-info (ça nécessite d'avoir un répertoire PORTLOG_DIR dans make.conf, pour activer les logs détaillés par ebuild)
-- TGL.
-- mailing list
Pierre Vignéras
Le Mardi 01 Février 2005 15:43, Yoann Pannier a écrit :
Pierre Vignéras wrote: > Mais, je trouve qu'un certain nombre d'outils ne sont pas encore assez > mature : revdep-rebuild me sort des trucs abracadabrantestque (par > exemple de remerger le jdk, puis une fois effectué, de remerger le jd k, > puis, ...) ! Le genre de choses qui mériterait des outils de tests > adaptés.
Pour le sun-jdk, s'il s'agit d'une machine sans serveur X, c'est normal que revdep-rebuild veuille le ré-installer. Le jdk inclus AWT qui a besoin d'X mais comme X n'est pas une dépendance du jdk (heureusement!), la ré-installation ne change rien.
C'est le problème des ebuilds binaires, et on peut avoir la même chose pour d'autres comme openoffice-bin ou firefox-bin (quand on est pas sous gnome par exemple je crois). Et ça se complique avec des binaires hors portage (genre oracle).
Je ne dis pas que ça fait propre ni que c'est bien comme ça, mais là revdep-rebuild fait exactement ce qu'on lui demande : proposer la réinstallation des paquets à qui il manque des dépendances à l'ex écution (enfin des .so quoi).
Oui, je ne dis pas que les outils ne font pas bien ce qu'ils sont censés faire (ou si je l'ai dit, ce n'est pas ce que je voulais dire, enfin bref), mais qu'il manque manifestement quelquechose pour qu'un upgrade se passe bien, sans heurts.
Au dernière nouvelles, mplayer et imlib ne compile plus (problème avec gif, de mémoire). Et ça, je trouve que pour une distrib supposé stable (pas d e ~x86), c'est qu'il y a un truc qui cloche !! Je ne sais pas quoi, mais ce n'est pa s le comportement que j'attends d'une distrib dite stable !
Pire, j'ai recommandé à un pote d'utiliser la Gentoo, parce que pour apprendre, on voit tout de suite ce qu'il se passe ! Mais d'un autre côt é quand un emerge ne termine pas (alors que c'est l'outil de base du systèm e, sinon à quoi bon une distrib, un LFS suffit), je trouve que cela manque d e sérieux. D'où les tests dont je parlais...
Bon, malgré tout, j'administre 4 bécanes dont un serveur LTSP, le tout à distance, c'est donc que je lui fait un peu confiance à la gentoo quand m ême. -- Pierre Vignéras
-- mailing list
Le Mardi 01 Février 2005 15:43, Yoann Pannier a écrit :
Pierre Vignéras wrote:
> Mais, je trouve qu'un certain nombre d'outils ne sont pas encore assez
> mature : revdep-rebuild me sort des trucs abracadabrantestque (par
> exemple de remerger le jdk, puis une fois effectué, de remerger le jd k,
> puis, ...) ! Le genre de choses qui mériterait des outils de tests
> adaptés.
Pour le sun-jdk, s'il s'agit d'une machine sans serveur X, c'est normal
que revdep-rebuild veuille le ré-installer. Le jdk inclus AWT qui a
besoin d'X mais comme X n'est pas une dépendance du jdk (heureusement!),
la ré-installation ne change rien.
C'est le problème des ebuilds binaires, et on peut avoir la même chose
pour d'autres comme openoffice-bin ou firefox-bin (quand on est pas sous
gnome par exemple je crois). Et ça se complique avec des binaires hors
portage (genre oracle).
Je ne dis pas que ça fait propre ni que c'est bien comme ça, mais là
revdep-rebuild fait exactement ce qu'on lui demande : proposer la
réinstallation des paquets à qui il manque des dépendances à l'ex écution
(enfin des .so quoi).
Oui, je ne dis pas que les outils ne font pas bien ce qu'ils sont censés faire
(ou si je l'ai dit, ce n'est pas ce que je voulais dire, enfin bref), mais
qu'il manque manifestement quelquechose pour qu'un upgrade se passe bien,
sans heurts.
Au dernière nouvelles, mplayer et imlib ne compile plus (problème avec gif, de
mémoire). Et ça, je trouve que pour une distrib supposé stable (pas d e ~x86),
c'est qu'il y a un truc qui cloche !! Je ne sais pas quoi, mais ce n'est pa s
le comportement que j'attends d'une distrib dite stable !
Pire, j'ai recommandé à un pote d'utiliser la Gentoo, parce que pour
apprendre, on voit tout de suite ce qu'il se passe ! Mais d'un autre côt é
quand un emerge ne termine pas (alors que c'est l'outil de base du systèm e,
sinon à quoi bon une distrib, un LFS suffit), je trouve que cela manque d e
sérieux. D'où les tests dont je parlais...
Bon, malgré tout, j'administre 4 bécanes dont un serveur LTSP, le tout à
distance, c'est donc que je lui fait un peu confiance à la gentoo quand m ême.
--
Pierre Vignéras
Le Mardi 01 Février 2005 15:43, Yoann Pannier a écrit :
Pierre Vignéras wrote: > Mais, je trouve qu'un certain nombre d'outils ne sont pas encore assez > mature : revdep-rebuild me sort des trucs abracadabrantestque (par > exemple de remerger le jdk, puis une fois effectué, de remerger le jd k, > puis, ...) ! Le genre de choses qui mériterait des outils de tests > adaptés.
Pour le sun-jdk, s'il s'agit d'une machine sans serveur X, c'est normal que revdep-rebuild veuille le ré-installer. Le jdk inclus AWT qui a besoin d'X mais comme X n'est pas une dépendance du jdk (heureusement!), la ré-installation ne change rien.
C'est le problème des ebuilds binaires, et on peut avoir la même chose pour d'autres comme openoffice-bin ou firefox-bin (quand on est pas sous gnome par exemple je crois). Et ça se complique avec des binaires hors portage (genre oracle).
Je ne dis pas que ça fait propre ni que c'est bien comme ça, mais là revdep-rebuild fait exactement ce qu'on lui demande : proposer la réinstallation des paquets à qui il manque des dépendances à l'ex écution (enfin des .so quoi).
Oui, je ne dis pas que les outils ne font pas bien ce qu'ils sont censés faire (ou si je l'ai dit, ce n'est pas ce que je voulais dire, enfin bref), mais qu'il manque manifestement quelquechose pour qu'un upgrade se passe bien, sans heurts.
Au dernière nouvelles, mplayer et imlib ne compile plus (problème avec gif, de mémoire). Et ça, je trouve que pour une distrib supposé stable (pas d e ~x86), c'est qu'il y a un truc qui cloche !! Je ne sais pas quoi, mais ce n'est pa s le comportement que j'attends d'une distrib dite stable !
Pire, j'ai recommandé à un pote d'utiliser la Gentoo, parce que pour apprendre, on voit tout de suite ce qu'il se passe ! Mais d'un autre côt é quand un emerge ne termine pas (alors que c'est l'outil de base du systèm e, sinon à quoi bon une distrib, un LFS suffit), je trouve que cela manque d e sérieux. D'où les tests dont je parlais...
Bon, malgré tout, j'administre 4 bécanes dont un serveur LTSP, le tout à distance, c'est donc que je lui fait un peu confiance à la gentoo quand m ême. -- Pierre Vignéras
-- mailing list
Pierre Vignéras
Le Mardi 01 Février 2005 20:49, Thomas de Grenier de Latour a écrit :
On Tue, 1 Feb 2005 15:13:28 +0100
Pierre Vignéras wrote: > En effet, mais c'est pas facile quand il y a n ebuilds, avec n > > >> 0 !!
Tu peux essayer ça: http://tdegreni.free.fr/gentoo/portlog-info (ça nécessite d'avoir un répertoire PORTLOG_DIR dans make.conf, pour activer les logs détaillés par ebuild)
J'ai effectivement PORTLOG_DIR dans make.conf.
Cet outil est *lent* mais intéressant. Ça m'arrive relativement souvent de regarder le contenu des logs...
Au passage comment nettoyez-vous le contenu de PORTLOG_DIR ?
Parceque ça ne sert à rien de garder des logs lorsque un ebuild a déj à été upgradé 5 fois !! Le premier d'entre eux n'a généralement plus d'int érêt.
J'ai 1760 fichiers de logs dans ce répertoire, dont les plus anciens date nt du 27 novembre dernier. Le problème c'est qu'on ne peut pas se fier à la d ate : il peut y avoir de vieux ebuild non encore upgradé. Il faut donc un truc un peu plus futé.
Vous rajoutez un truc dans tmpwatch ou vous vous êtes fait un script au p etit oignons ?
-- Pierre Vignéras
-- mailing list
Le Mardi 01 Février 2005 20:49, Thomas de Grenier de Latour a écrit :
On Tue, 1 Feb 2005 15:13:28 +0100
Pierre Vignéras <eipi@nerim.net> wrote:
> En effet, mais c'est pas facile quand il y a n ebuilds, avec n
>
> >> 0 !!
Tu peux essayer ça:
http://tdegreni.free.fr/gentoo/portlog-info
(ça nécessite d'avoir un répertoire PORTLOG_DIR dans make.conf,
pour activer les logs détaillés par ebuild)
J'ai effectivement PORTLOG_DIR dans make.conf.
Cet outil est *lent* mais intéressant. Ça m'arrive relativement souvent de
regarder le contenu des logs...
Au passage comment nettoyez-vous le contenu de PORTLOG_DIR ?
Parceque ça ne sert à rien de garder des logs lorsque un ebuild a déj à été
upgradé 5 fois !! Le premier d'entre eux n'a généralement plus d'int érêt.
J'ai 1760 fichiers de logs dans ce répertoire, dont les plus anciens date nt du
27 novembre dernier. Le problème c'est qu'on ne peut pas se fier à la d ate :
il peut y avoir de vieux ebuild non encore upgradé. Il faut donc un truc un
peu plus futé.
Vous rajoutez un truc dans tmpwatch ou vous vous êtes fait un script au p etit
oignons ?
Le Mardi 01 Février 2005 20:49, Thomas de Grenier de Latour a écrit :
On Tue, 1 Feb 2005 15:13:28 +0100
Pierre Vignéras wrote: > En effet, mais c'est pas facile quand il y a n ebuilds, avec n > > >> 0 !!
Tu peux essayer ça: http://tdegreni.free.fr/gentoo/portlog-info (ça nécessite d'avoir un répertoire PORTLOG_DIR dans make.conf, pour activer les logs détaillés par ebuild)
J'ai effectivement PORTLOG_DIR dans make.conf.
Cet outil est *lent* mais intéressant. Ça m'arrive relativement souvent de regarder le contenu des logs...
Au passage comment nettoyez-vous le contenu de PORTLOG_DIR ?
Parceque ça ne sert à rien de garder des logs lorsque un ebuild a déj à été upgradé 5 fois !! Le premier d'entre eux n'a généralement plus d'int érêt.
J'ai 1760 fichiers de logs dans ce répertoire, dont les plus anciens date nt du 27 novembre dernier. Le problème c'est qu'on ne peut pas se fier à la d ate : il peut y avoir de vieux ebuild non encore upgradé. Il faut donc un truc un peu plus futé.
Vous rajoutez un truc dans tmpwatch ou vous vous êtes fait un script au p etit oignons ?
-- Pierre Vignéras
-- mailing list
Thomas de Grenier de Latour
On Wed, 2 Feb 2005 10:28:33 +0100 Pierre Vignéras wrote:
Cet outil est *lent* mais intéressant.
Heu, ouais, c'est clair. Il serait un peu accélérable, mais je m'y suis jamais repenché. C'est vachement moins pire ceci dit si tu utilises l'option "-s <durée>", qui ne cherche que dans les logs vieux de moins de "<durée>". Genre "portlog-info -s 1d" ("1d" c'est pour 1 jour) après une mise à jour du world fait en général l'affaire.
Au passage comment nettoyez-vous le contenu de PORTLOG_DIR ?
Perso j'ai ajouté mon /var/log/portage dans le cron job "tmpreaper" (ou tmpwatch, effectivement, ça ferait l'affaire aussi). J'y vire les fichiers vieux de plus de 15 jours. Certes, ça vire des logs de paquets qui sont encore installés, mais bon, en principe je les ai déjà lu de toute façon (le tout, c'est de prendre le pli d'utiliser portlog-info après chaque mise à jour ou presque).
Enfin bon, faut bien voir que tout ça reste un hack dégueux basé sur le peu que portage rend possible. Des solutions plus propres nécéssiteraient des modifications au niveau de portage, qui pour des raisons étranges n'ont jamais été integrées, depuis bien un an qu'elles trainent sur le bugzilla...
-- TGL.
-- mailing list
On Wed, 2 Feb 2005 10:28:33 +0100
Pierre Vignéras <eipi@nerim.net> wrote:
Cet outil est *lent* mais intéressant.
Heu, ouais, c'est clair. Il serait un peu accélérable, mais je m'y
suis jamais repenché. C'est vachement moins pire ceci dit si tu
utilises l'option "-s <durée>", qui ne cherche que dans les logs
vieux de moins de "<durée>". Genre "portlog-info -s 1d" ("1d"
c'est pour 1 jour) après une mise à jour du world fait en général
l'affaire.
Au passage comment nettoyez-vous le contenu de PORTLOG_DIR ?
Perso j'ai ajouté mon /var/log/portage dans le cron job
"tmpreaper" (ou tmpwatch, effectivement, ça ferait l'affaire
aussi). J'y vire les fichiers vieux de plus de 15 jours. Certes,
ça vire des logs de paquets qui sont encore installés, mais bon,
en principe je les ai déjà lu de toute façon (le tout, c'est de
prendre le pli d'utiliser portlog-info après chaque mise à jour ou
presque).
Enfin bon, faut bien voir que tout ça reste un hack dégueux
basé sur le peu que portage rend possible. Des solutions plus
propres nécéssiteraient des modifications au niveau de portage,
qui pour des raisons étranges n'ont jamais été integrées, depuis
bien un an qu'elles trainent sur le bugzilla...
On Wed, 2 Feb 2005 10:28:33 +0100 Pierre Vignéras wrote:
Cet outil est *lent* mais intéressant.
Heu, ouais, c'est clair. Il serait un peu accélérable, mais je m'y suis jamais repenché. C'est vachement moins pire ceci dit si tu utilises l'option "-s <durée>", qui ne cherche que dans les logs vieux de moins de "<durée>". Genre "portlog-info -s 1d" ("1d" c'est pour 1 jour) après une mise à jour du world fait en général l'affaire.
Au passage comment nettoyez-vous le contenu de PORTLOG_DIR ?
Perso j'ai ajouté mon /var/log/portage dans le cron job "tmpreaper" (ou tmpwatch, effectivement, ça ferait l'affaire aussi). J'y vire les fichiers vieux de plus de 15 jours. Certes, ça vire des logs de paquets qui sont encore installés, mais bon, en principe je les ai déjà lu de toute façon (le tout, c'est de prendre le pli d'utiliser portlog-info après chaque mise à jour ou presque).
Enfin bon, faut bien voir que tout ça reste un hack dégueux basé sur le peu que portage rend possible. Des solutions plus propres nécéssiteraient des modifications au niveau de portage, qui pour des raisons étranges n'ont jamais été integrées, depuis bien un an qu'elles trainent sur le bugzilla...
