Petit tuto pour revenir à une ancienne version, de manière hyper-simple.
Dans l'exemple, je prends le pilote graphique xf-video-intel.
a) Installer le paquet downgrade
sudo pacman -S downgrade résolution des dépendances... recherche des conflits entre paquets...
Paquets (1): downgrade-5.0.3-1
Taille totale de téléchargement : 0,00 MiB Taille totale installé : 0,08 MiB
:: Procéder à l'installation ? [O/n] o :: Récupération des paquets... downgrade-5.0.3-1-any 4,9 KiB 814K/s 00:00 [-----------------------------] 100% (1/1) vérification des clés dans le trousseau [-----------------------------] 100% (1/1) vérification de l'intégrité des paquets [-----------------------------] 100% (1/1) chargement des fichiers des paquets [-----------------------------] 100% (1/1) analyse des conflits entre fichiers [-----------------------------] 100% (1/1) vérification de l'espace disque disponible [-----------------------------] 100% (1/1) installation de downgrade [-----------------------------] 100% Dépendances optionnelles pour downgrade sudo: for installation via sudo[installé]
chargement des paquets… Avertissement: retourne à la version antérieure du paquet xf86-video-intel (2.99.912-1 => 2.99.911-1) résolution des dépendances... recherche des conflits entre paquets...
Paquets (1): xf86-video-intel-2.99.911-1
Taille totale installé : 1,96 MiB Taille de mise à jour net : -0,09 MiB
:: Procéder à l'installation ? [O/n] o (1/1) vérification des clés dans le trousseau [#####################] 100% (1/1) vérification de l'intégrité des paquets [#####################] 100% (1/1) chargement des fichiers des paquets [#####################] 100% (1/1) analyse des conflits entre fichiers [#####################] 100% (1/1) vérification de l'espace disque disponible [#####################] 100% (1/1) réinstallation d'une ancienne version xf... [#####################] 100%
add xf86-video-intel to IgnorePkg? [y/n] y
Le paquet downgradé (xf86-video-intel) a été rajouté dans les paquets à ignorer pour les mises à jour à venir. Ainsi il restera bloqué sur la version qui va bien.
Desktop - Manjaro-KDE x86_64 Stable / Arch-KDE x86_64 - CPU : Intel® i5-3570K @ 3.40GHz - RAM 8 GO - Carte-mère : MSI Z77A-G45
Carte graphique : Intel® HD Graphics 4000 - Audio device: Intel Corporation Panther Point High Definition Audio Controller Laptop – Manjaro-XFCE x86_64 - CPU : Intel Pentium Dual-Core B940 - Carte graphique : Intel HD Graphics 3000
C'est juste magique. Lors de la dernière mise à jour (tout à l'heure !), mon paquet wine-staging a été upgradé. Je relance mon jeu favori du moment (je rejoue à Anarchy Online 17 ans après avoir quitté le jeu - j'ai été un des premiers joueurs au tout début !), genre nostalgie quoi.. Pas de bol, un bug, ça se lance pas. N'ayant pas le courage de me lancer dans une chasse au bug, je me dis que la version précédente de wine-staging fonctionnait fort bien avec ce jeu. Un petit coup de :
downgrade wine-staging
, et trois minutes plus tard je retrouve mon cher univers en 3D un peu pourri (d'il y a 17 ans donc). Vraiment puissant ce downgrade !
System: Kernel: 6.1-MANJARO x86_64
Desktop: Xfce, Distro: Manjaro Linux
"Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher"
Antoine de Saint-Exupéry
en fait je trouve cela beaucoup trop dangereux pour un utilisateur classique. Tout va bien si il utilise le cache local mais sinon il va télécharger dans les dépôts archlinux et non manjaro.
"Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher"
Antoine de Saint-Exupéry
Bonjour,
Je reviens sur ce fil de discussion car il m'est arrivé d'utiliser downgrade que je trouve effectivement très pratique et qui offre une certaine sécurité lorsqu'un paquet mis à jour pose problème.
En dehors du cache local, il utilise effectivement les dépôts Arch Linux.
Si je ne m'abuse les paquets Manjaro sont testés une semaine de plus que ceux de Arch.
Question : les paquets validés par les mainteneurs de Manjaro ne sont-ils pas en grande partie les mêmes que ceux de Arch ?
En même temps, vu la capacité des disques durs d'aujourd'hui, je pense qu'il est sage de garder un minimum de versions en cache (3 par défaut il me semble). Mais ça ne suffit pas toujours. La dernière fois que j'ai utilisé downgrade (il y a peu de temps) c'était pour revenir à la version 1.8.0 de libinput (mon clavier de portable ne fonctionnait plus, mais heureusement le clavier externe oui). On est aujourd'hui en version 1.9.4-1. J'ai donc dû retourner une dizaine de versions en arrière ! Merci downgrade
Bien entendu, ce n'est pas la panacée. Avant de downgrader un paquet, il faut déjà savoir quel paquet pose problème. Et ce n'est pas toujours évident.
Quant à AUR, il y a un post dans ce forum qui fourni des liens vers des dépôts d'archives, mais ils m'ont l'air anciens et peu utilisables aujourd'hui
Donc le cache est essentiel mais dowgrade peut aussi être d'un grand secours
Enfin, c'est mon avis.
Oui, les devs de Manjaro utilisent les mises à jour d'Arch, ce qui ne veut pas dire qu'ils les intègrent tous directement sans les adapter, mais la plupart est compatible .
Il est vrai que les DD sont de plus en plus performants tant en rapidité qu'en capacité, mais conserver des paquets devenus trop obsolètes ne sert pratiquement à rien. Hors avec une rolling, /var/cache/pacman/pkg se remplit vite. A voir selon ses disponibilités .
Nos devs gèrent tous les paquets officiels et malheureusement ne peuvent intégrer l'ensemble de ce que nous aimerions avoir. C'est là que les utilisateurs entrent en jeu en proposant des paquets sous forme de PKGBUILD aux standards Arch qu'on peut aisément installer. Le problème est que les utilisateurs ne sont pas toujours de bons développeurs ou ont trop a faire de leur côté et il est difficile de suivre le mouvent perpétuel imposé par le concept de la Rolling..
Par contre, les pilotes propriétaires d'imprimante par exemple ne se trouvent essentiellement que sur Aur, donc difficile de s'en passer.
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
Tout à fait d'accord avec toi lemust83.
Et pour éviter que mon cache ne prenne trop de place si j'oublie de faire du ménage, je me suis ajouté un alias :
alias dist-upgrade='yaourt -Syyuu && paccache -vvvrk2'
Je sais... le nom ressemble étrangement à une action de apt. C'est une déformation qui vient de mon ancienne distrib de prédilection.
Un point qui me choque dans ton alias est < yaourt -Syyuu>. On passe le fait que yaourt soit en fait un front-end de pacman qui devrait plutôt être invoqué directement, non ce qui m'interpelle est l'emploi du double <uu> qui signifie "Permet le rétrogradation d'un paquet si présent dans les dépôts ". En gros, on ne s'en sert que pour revenir d'une branche à une autre ou lors de rétro-pédalage des devs sur une mise à jour délicate. En tout cas, ce ne devrait pas être dans un alias, puisque cette commande est une correction de trajectoire.
Donc la bonne commande devrait être pacman -Syyu . Le double <yy> lui est nécessaire car le simple <y> est récemment déprécié . Le principe est de forcer pacman à utiliser le dernier fichier de conf généré par pacman-mirrors -F0.
Quant au cache de pacman, lui aussi devrait faire l'objet d'une action ad-hoc et non automatisée.
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
Merci pour ta remarque sur le double <uu>. En fait, je me dis que si les devs ou les mainteneurs de Manjaro proposent une rétrogradation de version c'est qu'ils ont une bonne raison. Alors pourquoi ne pas les suivre ?
Quant au fait que je mets yaourt plutôt que pacman, c'est juste que j'ai pris l'habitude d'utiliser uniquement yaourt en ligne de commande puisqu'il est effectivement un frontend de pacman. Mais ici, je suis d'accord qu'il n'y a pas d'avantage à utiliser yaourt.
Tout dépend de la confiance que l'on accorde aux devs, aux mainteneurs de la distrib, et aux miroirs de dépôts.
Je pense qu'il ne devrait pas y avoir d’ambiguïté quant à la confiance qu'on accorde aux devs et aux mainteneurs (et testeurs). Sinon, pas la peine de rester sur Manjaro car ça signifie qu'on n'a pas confiance en la distrib.
Par contre, cela peut être plus délicat concernant les miroirs.
Personnellement, je ne change pas de dépôts tous les jours. Alors, je me dis qu'il vaut mieux que je sois en phase avec mes miroirs de dépôts même si ils peuvent avoir du retard sur les mises à jours.
Cependant, comme dit plus haut, si les mainteneurs estiment qu'un paquet doit être rétrogradé, je pense qu'il vaut mieux leur faire confiance. Je suis déjà tombé sur ce cas de figure. Mais j'ai l'impression que c'est rare.
Mais le choix n'est vraiment pas simple, car il m'est aussi arrivé qu'un miroir ne soit pas disponible. Dans ce cas, pacman en utilise un autre dans la liste pacman-mirrors. Et si le deuxième n'était pas à jour ? Dans le cas de l'utilisation de <uu>, il rétrograderait probablement mes paquets !?
Pour ou contre l'utilisation du double "u", pour moi, le choix n'est pas simple
le cas <uu> est un retour sur la version n-1 des dépôts de manjaro , qui permet de se synchroniser vis à vis des mirroirs, l'autre solution étant de connaître le package fautif et utilisation de downgrade ,
mais cela fonctionne jusqu'à la prochaine mise à jour pour le downgrade , c'est donc une solution temporaire.
dans le cas <uu> , on a eu récemment la mise à jour du microcode pour intel , on attends la bonne mise à jour sur ce dernier point, l'equipe de dev Manjaro a fait retour arrière de leur côté et il faut dans ce cas appliquer un <uu>
sinon pour les autres mises a jour yyu est préférable pour forcer la synchro avec les miroirs
C'est exact, il y a eu une rétrogradation d'intel-ucode récemment.
C'est un exemple qui me laisse penser que l'utilisation de <uu> n'est pas mauvaise (et que mes miroirs font leur job).
Mais si on utilise tout le temps <u>, comment savoir quand un retour de version est proposé ?
L'utilisation de <uu> n'est évidemment pas mauvaise puisque c'est prévu pour permettre une retrogradation d'un paquet ou ensemble de paquets. Ce que je pense est que ce ne devrait pas être une commande invoquée systématiquement dans un alias. Quand les devs ont poussé un paquet qui s'avère bugué, ils proposent généralement de revenir à la version précédente en attendant de corriger le paquet qui du coup passera à la version supérieure.
Cette option n'est en fait que rarement nécessaire en Stable.
Pour Intel-ucode, c'est un peu panique-à-bord chez Intel et ils libèrent des patchs à tout va au petit bonheur. Nos devs Arch et Manjaro ne peuvent que suivre les parutions et permettre des marche-arrière quand il jugent urgent de le faire.
La norme est donc # pacman -Syyu .
Si un paquet est rétrogradé dans les dépôts, tu auras un message du type:
La version <paquet> est plus récente que....
Là, il faut être seul maître à bord car il n'y a pas de règle absolue.
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
Donc je suis prévenu s'il y a des paquets proposés en downgrade même si je fais un pacman -Syyu.
Merci pour l'info
Tu m'as convaincu, je modifie mon alias.
Merci !