Je ne vous apprends sans doute rien en vous disant à quel point les systèmes de paquetages des distributions Linux sont tout bonnement géniaux ! Gestion des dépendances, des conflits, méta-paquets, …
Là où ça devient un tout petit moins drôle, c'est quand le mainteneur d'un paquet fait une boulette : là, ça peut vite devenir l'enfer, si on ne fait pas gaffe ou, cas plus probable et moins grave, ça peut tout simplement bloquer l'installation/mise à jour.
C'est ce qui m'est arrivé hier, en voulant mettre à jour mon ArchLinux : un petit coup de yaourt -Syu
, un contrôle de la liste des paquets qui vont être mis à jour et zou, je valide !
Et là, un message de conflit entre 2 paquets, me disant :
Le paquet
machin
est en conflit avecmachin
. Voulez-vous supprimermachin
?
Tu relis, tu t'essuies les yeux, tu relis encore, tu regardes la date (non, on n'est pas le 1° avril…), tu annules, relances la mise à jour (pensant qu'un listing d'un des repositories ne s'est peut-être pas fait correctement) et tu recommences : pareil !
Si tu dis non, ça échoue. Si tu recommences et que tu dis oui, ça échoue !
Tu en viens à chercher si le paquet machin
n'est pas en doublon sur 2 repositories : non. Tu regardes alors ses infos et là :
Yaourt -Si
machin
[…] #plein d'autres infos sur le paquet
en conflit avec :machin
Ah oui ! Ça va beaucoup moins bien marcher, maintenant…
Bon, il faut saluer la réactivité de la communauté ArchLinux : le problème a été très vite corrigé (j'ai retenté 1-2h après, et c'était bon).
Et pour la petite histoire, c'était le paquet extra/kdesdk-je-sais-plus-quoi…
# Des noms! des noms!
Posté par saltimbanque (site web personnel) . Évalué à 5.
il faut couper la tête à ce gars là :)
heureusement les paquets meurent. on n'installe plus que
* un navigateur web (webkit évidemment)
* steam dans /opt
* éventuellement, la dernière release gnome avec ostree pour troller
[^] # Re: Des noms! des noms!
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3.
Tiens, parlant de paquets et de Gnome, j'ai été très surpris de réapprendre l'existence du projet AppStream dans ce billet de Richard Hugues (qui prépare le futur équivalent Gnomesque de la Logithèque Ubuntu).
Vous en pensez quoi, de son idée ? Je ne m'y connais pas beaucoup en gestionnaire de paquets, mais j'aimerais bien avoir un dispositif sur mon Arch aussi agréable et fiable à utiliser que la Logithèque sur Ubuntu (j'utilise Gnome PackageKit, mais il ne couvre pas tous les cas de figure et capote par moments).
[^] # Re: Des noms! des noms!
Posté par saltimbanque (site web personnel) . Évalué à 1.
c'est vrai que si chacune réinvente la roue on n'avance pas. un outil commun ça me parait l'idéal
# il porte bien son nom ce frontal
Posté par Mme Michu-cide . Évalué à 6.
Tu as vite fait d'y patauger dedans!
# Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par totof2000 . Évalué à 7.
Pas forcément un paquet en conflit avec lui-même, mais presque …. Et contrairement à ton cas, les résolutions de problèmes ne sont pas toujours aussi rapides : il faut parfois 1 à 2 jours (avec machine inutilisable pendant ce temps) pour que le problème soit réglé (ou avoir une nuit blanche à passer pour essayer de régler soi-même).
C'est un point non négligeable à mettre dans la balance lorsqu'on choisit Arch.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par paulez (site web personnel) . Évalué à 5.
Machine inutilisable pendant 1 ou 2 jours à la suite d'une maj de arch ? Ça ne m'est jamais arrivé pourtant… Après c'est vrai que des fois il faut lire la page d'accueil du site de arch et faire ce qui est écrit, en effet ça ne marche pas toujours tout seul.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par Dr BG . Évalué à 8.
Si la mise à jour ne se fait pas à cause d'un conflit, ce n'est généralement pas si grave, le système n'est simplement pas le plus à jour.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par totof2000 . Évalué à 0.
Ca peut juste casser une dépendance qui peut rendre tout ou partie du système inutilisable. Tout c'est rare (j'avoue que ça ne m'est jamais arrivé), mais une partie de KDE ou XFCE, ou autre soft dont tu as besoin, ça peut arriver (je sais il y a les sauvegardes, mais bon … ). Juste une question: est-ce qu'il y a un système de rollback lors de la mise à jour des paquets sous Arch ? Sinon, est-ce qu'une distribution aurait ça dans son système de paquets ? J'en ai jamais eu besoin ailleurs, mais ne sait-on jamais, ça peut servir …
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par gnumdk (site web personnel) . Évalué à 1.
http://arm.konnichi.com/2013/
Tu as tous les paquets à cet endroit, en cas de problème, il suffit d'aller chercher le paquet fautif et de le downgrader…
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par totof2000 . Évalué à 4.
Et le système de paquets est capable de downgrader tous les packages dépendants de celui qui délire ou faut-il tout se taper à la main ?
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par gnumdk (site web personnel) . Évalué à 0.
Non, il faut le faire à la main mais bon, les dépendances d'Arch sont suffisamment souple pour que je n'ai jamais eu besoin de le faire.
[^] # Des trucs de ce genre me sont arrivés que très rarement.
Posté par Sylvain Blandel . Évalué à 6. Dernière modification le 07 mars 2013 à 15:07.
Le comportement (par défaut) du gestionnaire de paquets est de conserver sur le disque dur tous les paquets téléchargés. Ce sont des fichiers
.pkg.tar.xz
stockés dans le répertoire/var/cache/pacman/pkg/
.Tous les paquets téléchargés sont stockés, y compris les différentes versions d'un même paquet. Par exemple, j'ai actuellement 6 versions du noyau linux :
Il est ensuite possible de réinstaller ces paquets avec :
Remarque : évidemment, tous ces paquets s'accumulent, ça finit par prendre de la place. Il faut faire du ménage de temps en temps. 😊
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par NilugeKiWi . Évalué à 7.
Chez moi pacman refuse de faire quoi que ce soit s'il a détecté un conflit pendant la mise-à-jour. Du coup pas d'upgrade, et pas de machine inutilisable pendant plusieurs jours…
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par Misc (site web personnel) . Évalué à 1.
Mais y a pas des gens pour mettre en place des tests d'upgrade avant de pousser les paquets sur les miroirs ?
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par Olivier Serve (site web personnel) . Évalué à 4.
Si, même qu'ils ont une infrastructure gigantesque avec toutes les configs possibles et sont payés des sommes mirifiques. C'est une honte, vraiment !
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par Misc (site web personnel) . Évalué à 3.
tester que ça marche est une chose ( en principe faisable, j'ai bien fait un script pour ça qui fait une install réseau et qui regarde si ça boote ). Tester que les paquets peuvent s'upgrader ou qu'il y a pas de deps cassés, c'est autre chose. Et des outils existent au moins pour les distros rpm et deb. Et y a rien de magique, suffit juste d'un serveur et d'un script.
Ensuite, peut etre que personne dans la communauté arch n'a de temps pour faire de la QA automatique, ce qui est triste.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par Olivier Serve (site web personnel) . Évalué à -1.
Puisque c'est si facile, je pense qu'ils seront enchantés de ta participation.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par Misc (site web personnel) . Évalué à 2.
Ma foi, c'est un bien gentil proposition, mais je suis déjà occupé à faire de la QA pour d'autres distros. mais je ne pige pas comment personne n'a jamais pris la peine de le faire. Ubuntu mise sur les tests automatisés pour un éventuel passage à une rolling release, et il semble que Fedora mise également beaucoup sur le projet autoqa pour ce genre de choses. Mageia a mis en place des tests à l'upload, des outils de verifs des paquets ( comme rpmlint ), etc. Debian aussi a des tonnes de verifs de partout.
Et pour montrer ce qu'on peut faire en une soirée, j'avais écrit ça : http://permalink.gmane.org/gmane.linux.mageia.devel/7446 , que hélas personne n'a mis en place après mon départ.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par gnumdk (site web personnel) . Évalué à 2.
La QA sous Arch, elle se fait dans [testing]… C'est un peu archaïque mais ça fonctionne plutôt bien…
L'auteur du journal ne précise pas d'ailleurs si il n'utilise pas testing par défaut.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par Spyhawk . Évalué à 2.
Tous les paquets ne passent pas par [testing] ou [community-testing]. Seulement les paquets susceptibles de casser quelque chose de critique et qui doivent être testés, et ceux qui nécessitent la recompilation d'autres paquets.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par Littleboy . Évalué à 3.
On les a perdu en meme temps que les gens qui testent l'install avec un des lecteurs cd les plus vendus sur le marche.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par Sylvain Blandel . Évalué à 1.
Je n'ai pas observé ce comportement chez moi. En cas de conflit, pacman propose de supprimer le paquet déjà installé, et d'installer le nouveau paquet.
Proposition : supprime manuellement le paquet déjà installé, puis ré-essaie de mettre à jour.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par O'neam Anne . Évalué à 2.
Il y a un utilitaire «downgrade» sur AUR qui est super bien pour ça. Je recommande.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par freem . Évalué à 2.
Pour Arch, je l'ignore, mais puisque tu demandes ce qui existe chez les autres distros, laisses-moi expliquer ce que je sais de Debian…
Pour Debian, si une dépendance est cassée, rien n'est fait, tout bonnement. Enfin, si, ça dit ce qui est cassé, et refuse d'agir tant qu'il n'y a aucune solution qui ne casse rien.
Alors, pour être franc, en ligne de commande, c'est pénible à utiliser… en revanche, l'interface ncurses d'aptitude permets de gérer la chose très simplement et intuitivement (pour l'interface GTK, j'en sais foutre rien, je la trouve mal branlée comme c'est pas permis.)
Ensuite, aptitude intègre un mécanisme de recherche de solutions, que je n'utilise pas, je préfère réparer à la main (voir pourquoi j'ai une cassure, et la fixer moi-même).
Ma réponse peut faire croire que les cassures de dépendances sont communes sur un système Debian, mais non, c'est simplement que je mixe testing, unstable et experimental, a coup d'apt-pinning, et parfois, une upgrade nécessite une mise à jour d'un paquet qui ne devrait pas être mis à jour selon les règles que j'ai établies. Dans ce cas, soit je les complète, soit j'impose au système d'utiliser la version expérimentale.
Ah, j'oubliais… apt et aptitude conservent également (par défaut) les paquets dans /var/cache/apt/archive. Ca peut dépanner parfois, mais ça bouffe de la place quand on ne nettoie pas les paquets obsolètes de temps et en temps et qu'on fait pas mal d'install/suppressions… quand je découvrais Debian, avec les install/suppressions de jeux, par exemple, saturer mon var m'est arrivé plus d'une fois :D
# Les paquets avaient des noms différents
Posté par Sylvain Blandel . Évalué à 4. Dernière modification le 07 mars 2013 à 14:44.
Bonjour.
J'ai également remarqué cette bizarrerie en mettant à jour mon Archlinux hier soir, il me semble toutefois que les 2 paquets avaient des noms légèrement différents.
Malgré le message signalant un conflit, j'ai accepté la mise-à-jour. Voici un extrait du fichier de log de pacman :
Pacman a retiré le paquet kdesdk-strigi-analyzer pour le remplacer par kdesdk-strigi-analyzerS
Notez le « S » final.
Malgré le message signalant un conflit, la mise-à-jour s'est bien déroulée. Je n'ai pas constaté de dysfonctionnement depuis.
[^] # Re: Les paquets avaient des noms différents
Posté par gnumdk (site web personnel) . Évalué à 3.
Et quand on regarde l'historique svn du paquet, on s'aperçoit que tu as raison et que l'auteur du journal raconte n'importe quoi ou ne sait pas lire… :p
[^] # Re: Les paquets avaient des noms différents
Posté par Spyhawk . Évalué à 3.
Non, l'auteur du journal se réfère simplement à un autre problème.
[^] # Re: Les paquets avaient des noms différents
Posté par gnumdk (site web personnel) . Évalué à 3.
Non, l'auteur du journal parlait d'un paquet en conflit avec lui même, ce n'est pas le cas ici non plus.
[^] # Re: Les paquets avaient des noms différents
Posté par Spyhawk . Évalué à 2.
Oops, tu as raison. J'ai bêtement pensé que l'auteur référait à différents paquets avec le seul terme "machin" puisque accepter le remplacement du paquet en conflit marche sans problème (ce qui n'était pas le cas avec kdesdk-dev-scripts).
[^] # Re: Les paquets avaient des noms différents
Posté par Sylvain Blandel . Évalué à 2.
Le journal n'est pas très clair. L'auteur ne nomme pas le paquet en question.
Quoiqu'il en soit, j'ai, moi aussi, failli me faire avoir. Plusieurs minutes me furent nécessaires pour remarquer que les paquets portaient des noms différents. :-)
[^] # Re: Les paquets avaient des noms différents
Posté par windu.2b . Évalué à 3.
Je n'avais pas répondu à ce flux de commentaires, parce que le tout premier m'a mis le doute : aurais-je donc mal lu le nom du paquet ?
N'étant pas retourné sur l'ordi en question depuis (oui, j'ai une vie sociale… :-p ), je n'ai pas encore vérifié les logs mais, de tous les exemples cités ci-dessus, le premier semble être celui qui se rapproche le plus de mon cas.
Et je n'ai pas nommé le paquet parce que je ne me souvenais plus de son nom exact : les logs me diront qui était le coupable !
[^] # Re: Les paquets avaient des noms différents
Posté par windu.2b . Évalué à 2.
C'était donc bien le coup du 's' en trop qui m'a trompé…
Par contre, le paquet 'extra/kdesdk-strigi-analyzer' (sans 's') n'existe plus :
Remplacé par kdesdk-strigi-analyzers :
[^] # Re: Les paquets avaient des noms différents
Posté par Sylvain Blandel . Évalué à 2.
Tiens, aujourd'hui j'ai ceci en faisant les mises-à-jour :
Là encore, les noms des deux paquets ne diffèrent que par un « S » final. Il y a vraiment de quoi se tromper ! :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.