[emerge] problème de mise à jour

[mobidyc]

Bonjour,

y a t'il un moyen pour transformer les erreurs de emerge en simple warnings de façon à ce qu'il ne s'arrête pas au moindre soubressaut?

actuellement, lorsque je liste les mises à jour disponibles avec un "emerge -pvNuD world", j'obtiens le résultat suivant:

Code: Select all

#> emerge -pvNuD world 2>/dev/null
These are the packages that would be merged, in order:

Calculating world dependencies -
!!! All ebuilds that could satisfy "=kde-base/konqueror-3.5*" have been masked.
!!! One of the following masked packages is required to complete your request:
- kde-base/konqueror-3.5.9 (masked by: ~x86 keyword)
- kde-base/konqueror-3.5.8 (masked by: package.mask)
/etc/portage/package.mask:
#


For more information, see MASKED PACKAGES section in the emerge man page or 
refer to the Gentoo Handbook.
(dependency required by "media-sound/amarok-1.4.8" [installed])

!!! Depgraph creation failed.

j'arrive à ne pas sortir en erreur en rajoutant l'option "--nodeps" mais ça limite beaucoup l'affichage des mises à jour et il y a des softs dont j'aimerais avoir une visibilité.

avez vous une idée, un flag à rajouter qui m'aurait échappé ou encore est-ce prévu dans une version future?

cdt,
Mobidyc

[Desintegr]

emerge veut installer konqueror mais il est masqué. Démasque le tout simplement et il n'y aura plus de problème.

[d2_racing]

Tu as quoi dans ton fichier /etc/portage/package.keywords ?

[mobidyc]

oui mais non,
ce n'est pas ce que je recherche.

dans cet exemple, amarok a été installé sans avoir besoin de konqueror et c'est pareil avec d'autres softs.
je n'ai pas envie de faire un emerge -pvNuD world 20 fois pour savoir quoi démasquer et voir la liste des mises à jour disponibles.

autant définir ACCEPT_KEYWORDS=~x86 ce que je n'ai pas envie car j'ai envie d'un minimum de stablilité.
dans ce cas précis, soit je démaske konqueror, soit je désinstalle amarok, éventuellement, j'ai vu qu'on pouvait faire un truc avec packages.provided mais ce fichier est écrasé à chaque sync.

l'idéal serait d'avoir le même type de résumé que lorsqu'un dépot est marqué blocked, ça n'arrête pas l'affichage des mises à jour disponibles et ça affiche un résumé en fin de listing.
mais ça doit pas exister (encore) je pense.

cdt,
Mobidyc

[Desintegr]

Amarok n'a pas besoin de Konqueror s'il est compilé sans le USE kde.

[mobidyc]

Tu as quoi dans ton fichier /etc/portage/package.keywords ?

environ 70 softs marqués unstables que j'ai choisis d'installer.
pourquoi?

cdt,
Mobidyc

[guilc]

Tu as quoi dans ton fichier /etc/portage/package.keywords ?

environ 70 softs marqués unstables que j'ai choisis d'installer.
pourquoi?

Ben voila, le problème vient de là
La nouvelle version instable de amarok demande la version instable de kde

Donc la solutino est simple : soit tu n'upgrades pas amarok (tu le repasse en stable, ou tu masques explicitement la 1.4.8 ), soit tu passes kde en instable.
Pas de demi-mesure possible sans trafiquer cradement les ebuilds...

C'est le problème d'être partiellement en ~x86 : cela demande de passer des paquets en cascade en ~x86...

Et s'imaginer que parceque tu as seulent 30 ou 40% de ta distrib en ~arch seulement, c'est plus stable que full ~arch, c'est illusion. C'est plutôt l'inverse : 100% en arch ou 100% en ~arch, c'est cohérent, et ça tourne bien. Maintenant mixer les 2, c'est aller au devant de problèmes d'incompatibilités non-gérés par les packageurs (pour parler clairement, c'est chercher rapidement la m****)

[mobidyc]

Donc la solutino est simple : soit tu n'upgrades pas amarok (tu le repasse en stable, ou tu masques explicitement la 1.4.8 ), soit tu passes kde en instable.
Pas de demi-mesure possible sans trafiquer cradement les ebuilds...

mon problème n'est pas la, je sais exactement pourquoi emerge fait des erreurs et je sais le corriger mais je voulais savoir s'il existait un moyen pour que emerge ne s'arrête plus en cas de depgraph dependency error.

j'ai pris le cas de amarok comme exemple mais je n'ai pas de problème particulier avec cette erreur si ce n'est que c'est lourd de voir emerge s'arrêter brutalement comme ça.
la gestion des packages bloqués est géniale, emerge ne s'arrête pas, les packages sont marqués en rouge et il est expliqué ou se situe le conflit en fin de listing, ce serait tellement plus simple d'avoir une gestion similaire pour les erreurs depgraph.

apparemment, il n'y a pas d'option à donner à emerge permettant un tel comportement, tant pis mais je pense que ce serait une bonne idée.

cdt,
Mobidyc

[polytan]

oui mais non,
ce n'est pas ce que je recherche.

l'idéal serait d'avoir le même type de résumé que lorsqu'un dépot est marqué blocked, ça n'arrête pas l'affichage des mises à jour disponibles et ça affiche un résumé en fin de listing.
mais ça doit pas exister (encore) je pense.

cdt,
Mobidyc

Moi j'ai compris ce que tu recherches et on répond à côté depuis le début...

Je n'ai pas la réponse, mais j'ai déja eu le soucis (et c'est chiant, un KEYWORDS="~x86" ne résoud pas) et je suis très intéressé par la solution

[guilc]

Donc la solutino est simple : soit tu n'upgrades pas amarok (tu le repasse en stable, ou tu masques explicitement la 1.4.8 ), soit tu passes kde en instable.
Pas de demi-mesure possible sans trafiquer cradement les ebuilds...

mon problème n'est pas la, je sais exactement pourquoi emerge fait des erreurs et je sais le corriger mais je voulais savoir s'il existait un moyen pour que emerge ne s'arrête plus en cas de depgraph dependency error.

j'ai pris le cas de amarok comme exemple mais je n'ai pas de problème particulier avec cette erreur si ce n'est que c'est lourd de voir emerge s'arrêter brutalement comme ça.
la gestion des packages bloqués est géniale, emerge ne s'arrête pas, les packages sont marqués en rouge et il est expliqué ou se situe le conflit en fin de listing, ce serait tellement plus simple d'avoir une gestion similaire pour les erreurs depgraph.

apparemment, il n'y a pas d'option à donner à emerge permettant un tel comportement, tant pis mais je pense que ce serait une bonne idée.

cdt,
Mobidyc

Il n'y a pas de solution, parceque la situation dans laquelle tu es est INSTABLE.
Le problème ici ce n'est pas emerge, c'est la situation foireuse dans laquelle tu te places volontairement avec un ensemble de version de packages inconsistant...
C'est une situation que tu ne devrais pas rencontrer dans une gestion de paquets saine.... Le gestionnaire de paquets n'a PAS à AUCUN MOMENT à affronter ce genre de situations. Seul l'utilisateur est ici fautif.
Enfin je dis ça, t'en fais ce que tu en veux... Mais ne viens pas pleurer quand tu auras complètement démoli ton système... Ca commence par amarok, ça finit par la glibc, et la, au moindre pet, c'est ton système que tu dézingues...

[d2_racing]

En effet, combien de fois Trevoke l'a dit, on passe en instable et c'est plus stable que la stable....euh quelque chose comme ça.Bref pour dire qu'on passe soit en x86 ou en ~x86, mais on doit passer au complet pour avoir un système sain.

[Kazuya]

Hello,
euh....moi j'ai toujours été en stable avec tout plein de packets tildarchés (vraiment beaucoup: kde, eclipse, emul-linux, alsa etc....), et j'ai un systeme vraiment stable je vois pas ou est le problème..... ?
Je ne comprends pas pourquoi vous dite qu'il ne faut pas faire comme ça alors que personnellement je trouve que c'est justement un des points fort de gentoo ?
Tildarché, plus stable que la stable...et moi j'enchaine sur l'histoire de la marmotte ...(vous savez le papier d'alu ).

Je connais une personne ayant testé la tildarché se plaindre des constantes mises à jours, des paquets foireux à la compilation etc ....et finalement revenir à une stable avec usage massif du package.keywords.

Donc j'ai grand besoin d'explications et de preuves comme quoi une gentoo instable est plus stable qu'une version stable avec usage massif du package.keywords
(Bien sur, en prenant en compte l'usage de ma machine: c'est à dire un besoin capital de tous les jours (etudes dans l'informatique...), donc je veux une machine qui soit vraiment stable tout en bénéficiant de logiciels à jour )

[d2_racing]

Je connais une personne ayant testé la tildarché se plaindre des constantes mises à jours, des paquets foireux à la compilation etc ....et finalement revenir à une stable avec usage massif du package.keywords.

En faisant ça, il se peut que tu arrives à briser des dépendances à cause qu'une version de package est incompatible avec une autre version etc... Alors si un package est en ~x86, sa dépendance a de forte chance d'être elle aussi en ~x86 pour régler le tout.

[polytan]

Après, ca n'est qu'une question de choix. J'aime avoir la dernière version disponible, mais si celle-ci n'est pas dispo, on est obligé d'attendre ou de demasquer.

Et démasquer des paquets en cascade, c'est chiant, on doit se les taper un par un.

[Desintegr]

Ben voila, le problème vient de là
La nouvelle version instable de amarok demande la version instable de kde

Je ne suis pas d'accord, le problème ne vient pas de là. Il n'y a pas de version instable d'Amarok :
http://packages.gentoo.org/package/media-sound/amarok

Si le USE kde est activé (c'est surement le cas sur le système de mobidyc), Amarok a besoin de =kde-base/konqueror-3.5* ou =kde-base/kdebase-3.5* comme dépendance.

Dans le cas présent, emerge choisit d'installer konqueror.
Il trouve donc dans l'arbre :
- kde-base/konqueror-3.5.9 (masqué car non stable)
- kde-base/konqueror-3.5.8 (stable mais masqué par le fichier /etc/portage/package.mask)
http://packages.gentoo.org/package/kde-base/konqueror

L'arbre des dépendances est donc inconsistant car Amarok a besoin de konqueror-3.5 qui ne peut être installé.
Il bloque donc la mise à jour et attend que l'utilisateur règle le problème.

Deux solutions sont possibles :
- désactiver le USE kde pour Amarok pour ne plus avoir konqueror comme dépendance
- démasquer konqueror (supprimer la ligne correspondante dans package.mask) et le rendre de nouveau disponible dans l'arbre Portage.

[mobidyc]

Hello,
SVP arretez de répondre en expliquant le pourquoi du comment de l'exemple que j'ai donnée.

je n'ai pas posté ce message pour résoudre ce problème mais pour savoir si une option (présente ou future) existait afin qu'emerge ne sorte plus en erreur dans le cas d'un depgraph dependency error.

je sais pourquoi j'ai ce problème (j'ai en effet masqué certaines versions de kde pour ne plus qu'il m'affiche ces mises à jour).

je veux avoir le choix d'installer ou non un package.
si le package que je veux installer demande une dépendance que je ne veux pas installer, emerge ne doit bien évidemment en installer aucun des deux, mais il serait bien plus agréable que cela ne soit pas bloquant pour le reste du traitement.

le python c'est pas mon dada, je n'ai ni l'envie ni le temps de m'y mettre mais si jamais quelqu'un en a la motivation voila une idée qui, je pense, fera gagner beaucoup de temps à tout le monde.

cdt,
Mobidyc

[Desintegr]

Je suis du même avis que guilc :

C'est une situation que tu ne devrais pas rencontrer dans une gestion de paquets saine.... Le gestionnaire de paquets n'a PAS à AUCUN MOMENT à affronter ce genre de situations. Seul l'utilisateur est ici fautif.

Le comportement d'emerge est normal et entièrement logique.
Mettons que tu veuilles mettre à jour le logiciel xyz, mais pour une raison quelconque, emerge ne peut pas résoudre l'arbre des dépendances.
Il s'arrête et au final rien n'est installé. C'est logique, le logiciel ne pourrait fonctionner correctement sans les dépendances.

world se comporte comme n'importe quel autre paquet et les paquets de world sont considérées comme des dépendances.
Une dépendance ne peux pas être mise à jour, tout world n'est pas mis à jour.

Dans l'exemple donné :
world à besoin d'amarok qui a besoin de konqueror.
Problème : konqueror ne peut pas être installé.
C'est donc inutile d'installer amarok puisqu'il ne fonctionnerait pas correctement sans konqueror.
C'est donc également « inutile » d'installer world puisque amarok ne fonctionne pas

Je trouve ce comportement parfaitement logique et personnellement, je n'ai pas envie que ça change.

[mobidyc]

world se comporte comme n'importe quel autre paquet et les paquets de world sont considérées comme des dépendances.
Une dépendance ne peux pas être mise à jour, tout world n'est pas mis à jour.

je ne suis absolument pas d'accord.
Une dépendance ne peux pas être mise à jour, le reste de world n'ayant pas de rapport avec cette dépendance devrait pouvoir s'installer.
par exemple, pourquoi le driver nvidia ne s'installerait pas si kde ne peut s'installer puisqu'il n'y a aucun rapport de dépendance.

comme je l'ai déjà dit, l'idéal serait le même comportement qu'un package bloqué.
emerge ne s'arrête pas si un package est bloqué et pourtant, il ne l'installera pas.

cdt,
Mobidyc

[Desintegr]

Une dépendance ne peux pas être mise à jour, le reste de world n'ayant pas de rapport avec cette dépendance devrait pouvoir s'installer.
par exemple, pourquoi le driver nvidia ne s'installerait pas si kde ne peut s'installer puisqu'il n'y a aucun rapport de dépendance.

Ce n'est pas le fonctionnement de emerge.
Et chez moi, quand des paquets sont BLOCKED, emerge s'arrête tout simplement et rien n'est installé :

Code: Select all

desintegr $ emerge vim gnome
Calculating dependencies... done!
[ebuild  N    ] net-libs/libsoup-2.2.105-r2  USE="ssl -debug -doc" 
[ebuild  N    ] gnome-extra/gnome-media-2.20.1  USE="mad ogg vorbis -debug -esd -ipv6" 
[ebuild  N    ] x11-libs/gtksourceview-1.8.5-r1  USE="-debug -doc" 
[...]
[ebuild  N    ] media-sound/cdparanoia-3.10_pre0-r1  
[ebuild   R   ] app-editors/vim-7.1.285  
[ebuild  N    ] gnome-extra/evolution-data-server-1.12.3  USE="ssl -debug -doc -ipv6 -kerberos -keyring -krb4 -ldap" 
[...]
[ebuild  N    ] media-sound/sound-juicer-2.20.1-r1  USE="ogg -debug -flac -test" 
[ebuild  N    ] gnome-base/gnome-2.20.3  USE="cdr dvdr -accessibility -cups -esd -ldap -mono" 
[blocks B     ] gnome-base/gnome (is blocking gnome-base/gnome-light-2.20.3)

 * 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

Cependant, tu as le droit de proposer une GLEP : http://www.gentoo.org/proj/en/glep/
Mais à mon avis, elle sera refusée.

Si j'ai bien compris, ce que tu veux, c'est qu'emerge affiche toute la liste des paquets à installer même quand il y a une erreur lors de la création de l'arbre de dépendance ?

[mobidyc]

Cependant, tu as le droit de proposer une GLEP : http://www.gentoo.org/proj/en/glep/
Mais à mon avis, elle sera refusée.

je viens de le faire, merci

Si j'ai bien compris, ce que tu veux, c'est qu'emerge affiche toute la liste des paquets à installer même quand il y a une erreur lors de la création de l'arbre de dépendance ?

oui, exactement.

[Desintegr]

Cependant, il y a une grande différence entre les paquets masqués et les paquets bloqués.

emerge --pretend affiche toujours ce qu'il va faire.

Dans le cas des paquets bloqués, ils sont disponibles dans l'arbre Portage. Il n'est juste pas possible de les installer simultanément.
emerge va donc calculer l'arbre des dépendances, afficher ce qu'il va faire et mettre un flag B pour les paquets qui posent problème.

Dans le cas des paquets masqués, ils ne sont pas disponibles dans l'arbre Portage.
emerge va donc calculer l'arbre des dépendances, mais il ne peut pas afficher ce qu'il va faire puisque les paquets qu'il veut installer ne sont pas disponibles.

[polytan]

Et bien, au minimum, il faudrait que les paquets qui ne posent pas de problème soient installer (après confirmation du travail qui se ra effectué, evidement)

Ensuite, j'aimerais une fonction d'emerge qui, pour les paquets non masqué mais aux dépendances masquées, propose un liste de paquet à démasquer (de manière récursive si les dépendances ont des dépendances masquées) pour que l'utilisateur voient (et en une seule commande) quels paquet il a besoin.

[CryoGen]

Bon qui n'a jamais ralé d'avoir son emerge world planté au mileu de la nuit par un des 1er paquet de la liste alors que tous les autres ne dépendent pas de lui ? C'est aussi pour ca qu'il y a skipfirst ...

Si le post ne concerne que le graph des dépendances y a rien a faire et c'est normal... si c'est quand une compile foire alors Paludis a une option pour ca

--continue-on-failure Whether to continue after a fetch or install error
if-fetch-only If fetching only (default)
never Never
if-satisfied If remaining packages' dependencies are satisfied
if-independent If independent of failed and skipped packages
always Always (UNSAFE)