Guix pour remplacer mon gestionnaire de paquets APT


  • Prédateur

    Deuxième article d’une série autour de Guix, après une brève introduction générale, voici un article plus programmatique sur le remplacement (ou la cohabitation) de l’outil apt par guix. Je précise qu’il s’agit de dépêches dont l’objectif est de vulgariser les notions phares de Guix et de les illustrer par des cas pratiques.

    Sommaire

    Introduction

    Guix étant un gestionnaire de paquets avant tout, il est tout naturel qu’il puisse constituer un remplaçant des autres gestionnaires de paquets existants.

    Si, comme moi (ou comme Bryan Lunduke), vous trouviez qu’il y a déjà trop de fragmentation dans le desktop et qu’il faudrait juste choisir une bonne fois pour toutes un format de paquet (par exemple les .deb) et un gestionnaire de paquets (par exemple apt) et ainsi avoir une compatibilité entre les distros, Guix (ou Nix, mais ce n’est pas le sujet de cette dépêche) pourrait être un bon candidat ! En effet, Guix a de nombreux avantages par rapport à ses concurrents :

    • il est transactionnel, ce qui signifie que si l’installation des paquets n’aboutit pas pour une raison ou pour une autre (p. ex. coupure d’alimentation), le système n’est pas impacté ;
    • il permet d’avoir plusieurs versions d’un même logiciel installées sur la même machine sans aucun conflit ;
    • il permet d’installer les paquets sans avoir les droits d’administration (oubliez sudo) ;
    • il est possible de revenir, à tout moment, à un état antérieur du système et donc être sûr de retrouver un état fonctionnel si jamais une mise à jour n’a pas fonctionné.

    Guix a d’autres avantages, mais déjà ces quatre‑là le rendent important.

    Guix pour remplacer APT

    Voici par exemple comment je remplace progressivement l’utilisation de apt (et snap par la même occasion) sur mon système Xubuntu 18.04.

    Installation

    Tout d’abord, j’ai installé Guix très facilement en suivant les instructions et l’installeur officiel.

    Ça se résume à :

    curl https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh | sudo bash
    

    Et à suivre les instructions à l’écran.

    Avant toute chose : gestion des locales

    Comme les paquets Guix ne sont pas forcément compilés avec la même libc que les paquets de notre système d’exploitation, il faut en premier lieu installer le paquet responsable de la gestion des locales de la libc, comme c’est précisé dans la doc :

    guix install glibc-locales

    Puis rajouter cette variable d’environnement à tous vos fichiers de session (.bashrc, .xsessionrc, etc.) :

    export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

    Sans cela, vous risquez d’avoir, comme moi, quelques problèmes.

    Installation de paquets

    Après avoir installé guix (voir plus haut), installer un paquet avec Guix est une opération très simple. J’ai commencé par remplacer certains paquets de ma distribution par des versions plus à jour. Par exemple (sans avoir les droits administrateur) :

    guix install libreoffice

    Qui est un alias de :

    guix package -i libreoffice

    Attention : la première installation de paquet peut prendre du temps (et de la place !) car Guix va chercher toutes les dépendances nécessaires à toutes les dépendances du paquet vu qu’il ne va utiliser aucune dépendance installée sur le système.

    Note : Vous verrez, certains paquets (ou correctifs) sont même compilés sur votre machine, mais dans l’ensemble, beaucoup de binaires précompilés (appelé substituts) sont disponibles (voir l’attribut builds dans la description des paquets).

    Toutes les dépendances téléchargées se trouvent dans le dossier /gnu/store. Voici un petit bout de mon dossier :

    $ ls --group-directories-first /gnu/store | less 01xnzx1q3k9z3xmhly0fa5ki8hp8l99s-libmwaw-0.3.15 023gvzf7gqbp61jfpc0674krwv7yiyza-mariadb-10.1.38 02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1 02k245xy33cvcnr8vm3lagm9zmb1s2wa-grep-3.1 03bgmiwcr3v5yh6psgh9dvg4qihb7qa0-xdg-desktop-database 03hd5wljl5yirh33czpi738ckq16zyp5-xdg-mime-database 04h27h0myyksngxx8imv416n4iwsiv8m-hunspell-1.7.0 04vqghzmpqzxpd94h1q931xpmazp5s7g-libgc-7.6.6 057dna3nwy84zdvfqss8vbgx1pzkdc2l-libungif-4.1.4 05zlxc7ckwflz56i6hmlngr86pmccam2-pcre-8.42 09x4p4ywz39xzy42kmscfi2nnhwjgybd-curl-7.64.0 0cnnj7kvggda2p12mlmxawz3ni9w5rwa-xcb-util-0.4.0 0fcp0xw1l1r2v42j4kdmn9ra3r7bd45v-gtk-im-modules 0fnyf3043x767xfm6gski5h1576q8wsn-glib-schemas 0h9x3hqqh4fx52735a7mykqm7mdkqnf4-libgc-7.6.6 0j6sz3bk4chqc8pgfv0fsn6byarwq4df-openldap-2.4.46 0j7xd8b63wv6hfssbacw28bj7rsbx0sk-packages 0ja63438w88gil4lxbpsgc5chmyiqhn6-openldap-2.4.46 0jif6gjzhxcg86q9qb7cjbcxdy8sacsn-python2-pygtk-2.24.0 0k450nckm9yp9vlbykvrb7pqp2njm3c4-libxv-1.0.11 0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3 0r1ihh22jhbii0n3xa4isgscbrynydfr-module-import 0wqgmqnlpr8pzvx4skqdgczym8384fbb-shishi-1.0.2 
    

    Comme vous pouvez le voir, toutes les dépendances se trouvent ici. Et dans chaque dépendance se trouve une arborescence propre.

    Par exemple :

    $ tree -d /gnu/store/01xnzx1q3k9z3xmhly0fa5ki8hp8l99s-libmwaw-0.3.15/ /gnu/store/01xnzx1q3k9z3xmhly0fa5ki8hp8l99s-libmwaw-0.3.15/ |-- bin |-- include | `-- libmwaw-0.3 | `-- libmwaw |-- lib | `-- pkgconfig `-- share `-- doc |-- libmwaw | `-- html `-- libmwaw-0.3.15
    

    Se trouve aussi maintenant dans mon répertoire personnel un dossier .guix-profile dont voici l’arborescence :

    tree -L 1 /home/dede/.guix-profile ~/.guix-profile |-- bin |-- etc |-- include |-- lib |-- libexec |-- manifest |-- sbin -> /gnu/store/8k4pnixpz73kxvxbjqajgbprjjmmgpxy-util-linux-2.32.1/sbin `-- share
    

    Le dossier bin contient des liens symboliques vers les binaires présents dans /gnu/store. On a ainsi un fonctionnement très flexible et je peux choisir très facilement à quelle version d’un logiciel attribuer tel ou tel alias.

    Le fichier qui nous intéresse est manifest, il décrit toutes les versions des logiciels installés et où ils se trouvent :

    (manifest (version 3) (packages (("tree" "1.8.0" "out" "/gnu/store/x5xb40q502s7pnqk9lmsnpc5vpsm1r8r-tree-1.8.0" (propagated-inputs ()) (search-paths ()) (properties)) ("recutils" "1.8" "out" "/gnu/store/wzk023ls4f7dq4mcc3kc86vskhw804n1-recutils-1.8" (propagated-inputs ()) (search-paths ()) (properties)) ("emacs" "26.2" "out" "/gnu/store/b38pn0gnj4jsrf79lg4kr80rn5kaim0q-emacs-26.2" (propagated-inputs ()) (search-paths [...]
    

    Utilisation des paquets

    Pour utiliser les paquets installés par Guix, quand on est en ligne de commande, il suffit de rajouter le dossier bin à notre $PATH :

    export PATH="/home/dede/.guix-profile/bin${PATH:+:}$PATH"
    

    Pour un usage serein, vous pouvez rajouter cette ligne à votre .bashrc si vous utilisez Bash ou .zshrc si vous êtes sous ZSH :

    # Guix # le fichier profile contient l’ajout de `bin` au `$PATH` GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$HOME/.guix-profile/etc/profile"
    

    Maintenant, quand vous tapez par exemple libreoffice, c’est la version Guix qui se lance et non plus celle installée sur votre système via apt et cela, sans aucune interférence, si ce n’est les fichiers de configuration qui se trouvent dans votre HOME qui seront partagés.

    Ici la version 6.1.5.2 de LibreOffice, alors que celle présente dans Xubuntu 18.04 est la 6.0.7. Dans ce cas‑là, Guix n’offre pas de paquet très à jour.

    Avec un lanceur graphique

    Si vous voulez que les lanceurs graphiques (les raccourcis dans le menu) lancent directement toutes vos applications Guix, vous n’avez qu’à modifier le fichier .xsessionrc en rajoutant la même ligne que dans votre .bashrc :

    # Guix # le fichier profile contient l’ajout de `bin` au `$PATH` GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$HOME/.guix-profile/etc/profile"
    

    Si toutefois vous souhaitez garder vos logiciels installés via apt et ne mettre à jour que quelques lanceurs, il est aussi possible de modifier les lanceurs graphiques en changeant simplement la commande d’exécution.

    Exemple, avec LibreOffice Writer, avant j’avais :
    libreoffice --writer %U

    Et j’ai simplement mis ça à la place :
    /home/dede/.guix-profile/bin/libreoffice --writer %U

    Après m’être assuré que le paquet Guix fonctionnait bien, j’ai pu faire une désinstallation du paquet installé via apt :
    sudo apt remove libreoffice

    Je fais ça petit à petit avec tous les logiciels que j’utilise. Ça me permet en quelque sorte d’avoir une « rolling release » tout en gardant le système auquel je suis habitué. C’est une introduction tout en douceur à Guix :).

    Désinstallation des paquets

    Il est bien sûr possible de désinstaller un paquet très facilement via guix remove libreoffice, alias de guix package -r libreoffice.

    Note : après un remove, Guix garde tout de même les fichiers dans /gnu/store mais supprime les liens symboliques dans votre guix-profile.

    Pour faire une vraie suppression, il faut faire un guix gc qui supprime tous les paquets inutilisés. Mais après quelques tests, certains paquets supprimés restent quand même, je ne sais pas pourquoi.

    Mise à jour des paquets

    Pour mettre à jour tous les paquets en même temps, il suffit de taper guix upgrade ou guix package -u. Si je veux simplement mettre à jour LibreOffice, par exemple, je peux faire :
    guix upgrade libreoffice

    Rechercher un paquet

    Pour rechercher un paquet, rien de plus simple, exemple avec libreoffice : guix search libreoffice, alias de guix package -s libreoffice.

    Bon, ça renvoie souvent beaucoup de paquets, pas forcément en lien, donc on peut simplifier l’affichage avec un grep :
    guix search libreoffice | grep -A 2 'name:' | less

    Voir affiner la recherche avec :
    guix search libreoffice | grep -A 2 'name: libreoffice' | less

    Après je ne suis pas un pro des petits outils en ligne de commande qui se chaînent (je n’ai que les rudiments) et je suis sûr que des personnes plus douées que moi font des merveilles pour avoir une recherche plus aisée.

    Bon, je ne vous conseille pas le site listant les paquets Guix, car il est tout bonnement inutilisable. Il ne contient même pas de formulaire de recherche…

    Mettre à jour Guix

    Vous pouvez aisément mettre à jour le logiciel Guix en tapant la commande suivante :
    guix pull

    Et si vous souhaitez connaître les dernières nouveautés ajoutées, vous pouvez faire un :
    guix pull --news

    Revenir en arrière suite à un problème

    Avec Guix il est possible de revenir à n’importe quelle « génération » (c’est le nom donné à chaque changement dans l’installation) de paquets sans souci.

    Je vais prendre un exemple concret, sous ma Xubuntu, j’ai git installé :

    git --version git version 2.17.1
    

    J’aimerais avoir une version plus récente, alors je fais un :

    guix install git
    

    J’ai maintenant un git plus à jour :

    git --version git version 2.21.0
    

    Si pour une raison ou une autre je veux revenir en arrière, je peux faire un « rollback » :

    guix package --roll-back git --version git version 2.17.1
    

    Ce qui est intéressant, c’est qu’en réalité, le logiciel reste présent dans le répertoire /gnu/store, il est seulement retiré du profil personnel. Cela rend la « navigation » dans les différentes générations très rapide et aisée.

    Exécuter une application en mode « bac à sable »

    Il est possible d’utiliser une application dans un espace isolé de l’environnement (appelé « container ») et ainsi protéger au maximum la distribution hôte.

    Exemple avec Midnignt Commander où l’on peut voir que les répertoires système et autres répertoires personnels ne sont pas accessibles :

    guix environment --ad-hoc --container mc # Il faut définir la variable TERM export TERM=xterm-256color mc
    

    Note : en jouant un peu avec cette commande, je me rends compte que ce n’est pas très utilisable pour des applications graphiques, car le conteneur n’a même pas accès au serveur X, donc son usage est un peu limité.

    Conclusion

    Guix (tout comme Nix) offre une vision novatrice, sécurisée et extrêmement souple de la gestion de paquets. L’installer sur une distribution hôte est très aisé et sans risque. C’est une expérience intéressante pour qui souhaite découvrir cet outil et accessoirement mettre à jour certains paquets.

    Si vous avez plus de questions, je vous invite à lire la FAQ ci‑dessous.

    FAQ

    Pour quoi faire ?

    Les PPA c’est pas plus simple ?

    Et Snap ?

    Snap est un gestionnaire de paquets qui se veut universel, mais qui pour l’instant est porté exclusivement par Canonical. Il offre des caractéristiques assez similaires à Flatpak mais permet aussi d’installer des logiciels sans nécessiter de pile graphique (ce qui n’est pas le cas de Flatpak à ma connaissance).

    Comme vu plus haut, Guix peut aussi avoir une exécution en mode bac à sable, avec sans doute moins de granularité possible sur les autorisations. Après, sans vouloir troller, Snap semble avant tout fait pour introduire des logiciels tiers (entendez par la provenant d’entreprises et n’étant pas audités par la communauté) dans la logithèque Ubuntu. Son slogan « _The app store for Linux » » en dit long…

    Je ne connais pas cet outil, mais, personnellement, je préfère faire confiance aux serveurs de paquets et à la communauté qui les construit qu’en un logiciel qui me permet d’exécuter des applications en lesquelles je n’ai pas confiance en mode « bac à sable » et me demandant des autorisations que j’accorderai forcément… Puis ça crée des disques virtuels et je n’aime pas ça.

    Et Flatpak ?

    Je ne peux que vous conseiller la lecture de l’excellente dépêche de nokomprendo qui compare Nix (logiciel très similaire à Guix) et Flatpak. Pour moi, Nix ou Guix sont plus intéressants que Flatpak.

    Et Nix alors ?

    D’un point de vue pragmatique, Nix est plus abouti (plus ancien) et bénéficie d’une beaucoup plus grosse communauté et donc d’un nombre plus important de paquets, qui sont sans doute plus à jour. Guix et Nix étant très proches dans leur fonctionnement, on est en droit se demander quel est l’intérêt de Guix.

    Nous tâcherons d’écrire une dépêche spécifiquement sur ce sujet, mais on peut déjà noter quelques spécificités de Guix par rapport à Nix qui rendent le projet attrayant et non redondant selon nous :

    • Guix est un projet GNU et Guix System est une distribution basée exclusivement sur du code libre, cet aspect est très important chez les contributeurs Guix ;
    • un énorme effort est fait pour rendre la distribution bootstrapable (désolé pour l’anglicisme) et ainsi pouvoir compiler l’ensemble des sources (même gcc) à partir d’un unique binaire très léger dont le code assembleur est lisible, ceci afin d’éviter les attaques dites de « trusting trust » ;
    • dans un but similaire, l’équipe de Guix cherche à avoir des builds reproductibles, c’est‑à‑dire avoir des binaires identiques pour une même entrée (mêmes sources et même fichier de configuration), ceci afin de pouvoir s’assurer que les binaires générés en local sont bien les mêmes que ceux proposés par le serveur, par exemple ;
    • Guix utilise GNU Shepherd à la place de systemd ;
    • Guix utilise pour la définition de ses paquets et la configuration du système le langage d’extension Guile ; à la différence du langage utilisé par Nix (Nix Expression Langugage), Guile est un langage généraliste s’interfaçant facilement avec des librairies C et étant utilisé dans (quelques) autres projets GNU, comme Shepherd par exemple — à noter qu’ils sont tous les deux des langages fonctionnels.

    Installer des paquets sans droits administrateur c’est pas un peu dangereux ?

    Non, pas vraiment. Le seul risque est qu’un utilisateur disposant des droits pour installer un paquet via le démon Guix pourra donc installer autant de logiciels qu’il veut et potentiellement remplir le disque dur. J’invite le lecteur à lire cet échange pour plus d’informations.

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    https://linuxfr.org/news/guix-pour-remplacer-mon-gestionnaire-de-paquets-apt