Petits conseils sur l’utilisation d’AUR sur Manjaro/Arch

Twitter Facebook Google Plus Linkedin email
closeCet article a été publié il y a 4 ans 7 mois 1 jour, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées, les commandes ne sont peut-être plus valides.

AUR, ça veut dire Arch User Repository. Pour les habitués d’Ubuntu c’est une sorte de super dépôt PPA où n’importe qui peut coller du paquet « maison » à destination d’Arch Linux (et dans 99% des cas de ses dérivées, dont Manjaro). Leur « forme » est très libre, et comme c’est entièrement géré par les utilisateurs, il y a quelques précautions à prendre.

L’idée me trottait déjà dans la tête depuis un moment, et une récente discussion avec Arowan sur XMPP m’a convaincu de vous prévenir sur les soucis potentiellement rencontrés par ce type de paquets.

En effet, dans ce tutoriel à destination des ubuntistes, on proposait d’installer PHPMyAdmin depuis un PPA perso, histoire d’avoir « la dernière version ». Problème, si on regarde le dépôt de près, aucune mise à jour depuis 43 semaines. Donc la version proposée est vulnérable à plusieurs failles de sécurité, contrairement à la version certes plus ancienne mais maintenue par l’équipe Canonical (qui se paie le luxe d’être plus récente en plus, un comble). Et certains suivront malgré tout les instructions les yeux fermés, évidemment.

Les paquets proposés sur AUR sont de la même trempe : ils sont sous l’entière responsabilité des utilisateurs. En plus, les « types » de logiciels proposés sont plus nombreux, certains paquets récupérant les sources d’un logiciel pour les compiler, d’autres n’étant que des convertisseurs de paquets deb en paquet xz, certains installant des dépendances depuis les dépôts standards de la distribution, d’autres utilisant d’autres dépendances sur AUR, du logiciel libre, du logiciel open-source, du logiciel propriétaire… Bref, c’est très puissant, mais ça peut vite être un beau merdier. En particulier quand un utilisateur laisse tomber son paquet, qui peut s’avérer cassé pour différentes raisons, principalement parce que Arch évolue continuellement (des noms de paquets peuvent changer, des versions peuvent devenir incompatibles…).

J’ai eu le tour avec dpluzz. C’est un logiciel qui permet de télécharger la vidéo d’un replay sur le service Pluzz de France 2 (quand on a pas d’autres solutions pour le voir sur la TV, et surtout le débit, un peu comme YouTube). dpluzz est développé et surtout testé uniquement sur Ubuntu. Un paquet AUR existe pour convertir et installer le logiciel sur Arch/Manjaro. Jusqu’à la version 1.2, tout allait bien. Les versions suivantes ont requis de nouvelles dépendances, et malgré leur existence, le logiciel a depuis refusé de se lancer sur ma machine. J’ai donc du me résoudre à trouver une autre solution (youtube-dl en l’occurence fait très bien l’affaire, une fois de plus).

Doit-on éviter à tout prix de l’utiliser ? Non certainement pas, mais il faut savoir prendre quelques précautions.

Limiter le nombre de paquets AUR

Puisque leur sort n’est pas entre vos mains ni entre ceux des créateurs de la distribution, le niveau de confiance que l’on peut apporter aux paquets AUR est forcément plus faible. Pour éviter de multiplier les problèmes, il faut alors éviter d’installer trop de paquets AUR. En particulier (ce n’est pas facile à savoir, mais pas impossible non plus), ceux qui installent leurs dépendances avec d’autres paquets AUR, surtout s’ils n’en sont pas l’auteur.

Qu’ai-je donc sur ma propre machine ?

  • XQF, un navigateur de serveurs de jeu
  • Vinetto, un outils pour récupérer les vignettes thumbs.db de Windows
  • Teamviewer, le logiciel de bureau à distance qu’on ne présente plus
  • Semantik, un outil de mind-mapping, que je commence seulement à découvrir
  • qstat (outil qui va avec XQF, pour les serveurs basés sur de l’idTech)
  • Fing, un analyseur de réseau
  • Opera, le navigateur non-libre basé sur Chromium (qui n’est téléchargeable sous Linux que sous forme de .deb)
  • Kronometer, pas besoin de description je pense
  • iwscanner, analyse de réseaux Wifi, très moche, mais fonctionnel
  • FSLint (que je compte vous présenter un jour),
  • Corebird, client Twitter beau et fonctionnel
  • apache-tools (utilisé pour tester HHVM)
  • 3ncode (mini logiciel de conversion, basé sur ffmpeg), découvert chez La vache libre

Certains de ces paquets ont malheureusement eu besoin d’autres dépendances provenant d’AUR. Quand ce ne sont pas des paquets vitaux, ce n’est pas grave (Semantik, 3ncode, Kronometer, Vinetto), mais pour d’autres, comme Opera, Fing, apache-tools, Teamviewer, bref, liés au réseau, ça pourrait s’avérer plus difficile. En particulier, Teamviewer laisse tourner un process en tache de fond, qui écoute sur le réseau. Dès lors, un attaquant pourrait tenter d’en profiter. Et la mise à jour de ce paquet critique dépend donc du mainteneur.

Vérifier l’activité d’un paquet

Pour voir la dernière mise à jour d’un paquet, on peut utiliser la commande suivante :

Je n’ai pas bien compris les erreurs de parsing, le paquet s’est pourtant installé correctement.

Je préfère le faire comme ça, parce qu’Octopi ne permet pas d’avoir les détails d’un paquet tant qu’il n’est pas installé. Une autre manière de faire est de se rendre sur le site aur.archlinux.org et de chercher le paquet dont on veut connaître l’activité. Là, on a aussi l’adresse du dépôt Github, on peut donc aller comparer avec l’activité originale du logiciel. En l’occurrence, on peut voir qu’on dispose bien de la dernière version stable (il existe un paquet corebird-git qui utilise la version en cours de développement).

Si un paquet commence à être trop en décalage avec l’actualité du logiciel, va falloir retrousser les manches.

Et si le logiciel vit toujours, mais pas le paquet ?

Si le paquet est dit orphelin, parce que son mainteneur a décidé de lâcher l’affaire (pour différentes raisons, on s’en fout, le résultat est le même), et qu’on veut alors mettre à jour le logiciel installé, pas le choix, faut un peu d’huile de coude. Je recommande alors de désinstaller le paquet, puis de se tourner vers la documentation dudit logiciel pour refaire une installation propre. Pas de panique à avoir cependant, tout bon logiciel sous Linux qui se respecte enregistre vos préférences dans un fichier/dossier caché de votre répertoire utilisateur. Lorsque vous lancerez votre nouvelle version fraîchement installée, il saura normalement aller lire ces préférences au bon endroit.

Le seul inconvénient, c’est qu’il faudra alors vérifier manuellement les mises à jour, et les installer tout aussi manuellement.

AUR, c’est bien quand même

AUR comme les PPA, comme les dépôts standards (et ça m’arrache la gueule de le dire, mais aussi les « stores » mobiles), simplifient grandement pour l’utilisateur la gestion des mises à jour des paquets. Et même si j’ai parlé des risques du fait que les paquets sont maintenus par des utilisateurs indépendants, les « apps » qu’on peut trouver sur les stores mobiles peuvent aussi ponctuellement en être victime : si votre smartphone est mis à jour et que le développeur d’une application n’a pas prévu de gérer la nouvelle version, vous pourriez rencontrer des problèmes.

Mais c’est quand même bien mieux d’installer et de mettre à jour des logiciels par un tel procédé plutôt que d’avoir à chercher partout un paquet à installer manuellement. On voit ce que ça donne au quotidien pour les utilisateurs de Windows, qu’on doit nettoyer à tour de bras…

Poster un Commentaire

avatar
  S’abonner  
Notifier de