Il est temps d'universaliser l'installation de packages sur Linux. PackageKit est là pour ça. Et vous l'avez déjà utilisé sans le savoir.

Si vous vous prenez la tête à toujours proposer des commandes apt, dnf, zypper, pacman ou emerge dans vos articles, vos scripts, Makefile ou autres, on va discuter de PackageKit.

Je suis le premier à faire ce genre de truc :

• je fais un article, je veux que les gens puissent installer un outil, un logiciel, blablabla,
• je suis sur Fedora, donc je connais le package à installer avec dnf,
• et je me dis “ha zut, il y a des gens sur Ubuntu, Debian, Arch Linux, openSUSE, Gentoo, etc.”,
• donc je me dis que, par respect, je vais leur proposer une ligne de commande pour “la plupart des distributions”

Et, à la fin, soit je me trompe de nom de package, soit le package a différentes variantes, soit j’oublie une distribution. Et en plus, je me démarre un conteneur (avec Podman) pour vérifier.

Idem quand je veux créer un script d’installation pour des utilisateurs finaux, ou un Makefile pour un truc général… je dois détecter la distribution, et proposer des commandes différentes.

Et pourtant, je le sais hein, je le sais que PackageKit existe, et que c’est fait pour ça.

Et j’oublie de l’utiliser. Donc, je vais vous en parler, et vous expliquer pourquoi je vais commencer à l’utiliser plus fréquemment. Je vais aussi vous dire quand ne pas l’utiliser.

D’abord, c’est quoi ça ?

PackageKit est un système de gestion de paquets qui abstrait les détails des gestionnaires de paquets. Il permet de proposer une interface commune pour installer, mettre à jour, supprimer des paquets, et ce, quelle que soit la distribution Linux utilisée.

Oui, c’est “universel” (enfin, presque).

En fait, “Gnome Software”, “Discover”, “Apper”, etc. utilisent PackageKit pour gérer les paquets. Il y a que les vieux barbus dans mon genre, ou les vieilles barbues (ouais, inclusion, tout ça) qui utilisent encore les commandes apt, dnf, zypper, pacman ou emerge directement.

Bon, attendez… on va se calmer.

Certes, PackageKit est un outil pratique, qui installe proprement les packages, et qui n’entre pas en conflit avec votre gestionnaire de paquet habituel (parce qu’il l’utilise). Le truc, c’est que c’est un outil “haut niveau”, qui ne permet pas de faire des choses spécifiques à une distribution.

C’est un outil, comment dire, “bureautique” ? Si vous devez faire un truc plus technique, avec des options particulières ou adapté à une distribution spécifique, vous devrez utiliser les commandes spécifiques à la distribution. Donc, ne pas utiliser PackageKit mais apt, dnf, zypper, pacman ou emerge.

Par contre, si vous êtes un rédacteur d’article, un développeur d’application qui demande d’ajouter des packages ou un éditeur qui est parfaitement au courant que son outil est dans les dépôts : PackageKit. Sérieux, faites un effort, il faut juste remplacer le mot “apt” par “pkcon”.

Parce que, m*@!#* à la fin ! J’en ai plus que marre de voir des gens n’écrire des commandes que pour Ubuntu/Debian et se foutre royalement des autres distributions. Je suis utilisateur de Fedora et je fais l’effort de toujours proposer des commandes apt et dnf - c’est le minimum syndical.

Mais même en faisant cet effort, je l’avoue, j’oublie Arch Linux, openSUSE, Gentoo, etc. Et je ne parle même pas des distributions plus exotiques.

Va falloir que ça devienne un réflexe.

Donc : PackageKit et la commande pkcon !

En mode graphique ?

Eh bien si vous avez un environnement de bureau, vous avez sûrement un gestionnaire de paquets qui utilise PackageKit. Par exemple, sous Fedora, vous avez “Gnome Software”. Sous Ubuntu, vous avez “Discover”. Sous openSUSE, vous avez “Apper”.

Tous utilisent déjà (en partie ou totalement) PackageKit pour gérer les paquets.

Ce que j’essaie de vous faire comprendre, c’est que si vous avez utilisé un gestionnaire de paquets graphique, vous avez déjà utilisé PackageKit.

Mais ce qui est cool, c’est que vous pouvez l’utiliser en ligne de commande, et ça, peu de gens le font.

PackageKit en ligne de commande

Linux, ça s’utilise graphiquement et c’est bien. Mais je ne connais pas un utilisateur qui, après peu de temps, n’ouvre pas un terminal pour utiliser son ordinateur plus “rapidement”.

La ligne de commande principale, c’est “pkcon”. Suivi d’une “commande” :

• pkcon install <package> pour installer un paquet
• pkcon remove <package> pour supprimer un paquet
• pkcon search <package> pour rechercher un paquet
• pkcon info <package> pour obtenir des informations sur un paquet
• et d’autres…

Ce qui est cool, c’est qu’Ubuntu, Fedora, openSUSE, Arch Linux, etc. ont tous PackageKit d’installé par défaut. La commande : pkcon

Je veux installer, par exemple, “Firefox”. Je vais donc utiliser la commande pkcon install firefox :

pkcon install firefox

Résolution                   [=========================]         
Chargement du cache           [=========================]         
Test des changements          [=========================]         
Terminé                      [                         ] (0%)  
Les paquets suivants doivent être installés :
 firefox-124.0.2-2.fc39.x86_64	Mozilla Firefox Web browser
 firefox-langpacks-124.0.2-2.fc39.x86_64	Firefox langpacks
 mozilla-openh264-2.4.0-2.fc39.x86_64	H.264 codec support for Mozilla browsers
Continuer avec ces changements ? [N/y] y

                             [=========================]         
Installation                  [=========================]         
Requête                      [=========================]         
Téléchargement des paquets  [=========================]         
Test des changements          [=========================]         
Installation des paquets      [=========================]         
Terminé                      [=========================]

Vous avez remarqué ? Pas besoin de sudo pour installer un paquet. PackageKit va demander les droits administrateurs si nécessaire. C’est tellement plus pratique…

Par exemple, j’ai demandé une réparation (inutile sur mon système, mais pour vous montrer…), j’ai donc tapé pkcon repair et le système m’a demandé les droits administrateurs :

Intéressant, car il me dit ce qu’il va faire, en l’occurrence, réparer les paquets cassés. Je peux donc annuler ou accepter avec mon mot de passe. Voilà, ça, c’est bien !

Et si je veux supprimer “Firefox”, je vais utiliser la commande pkcon remove firefox :

pkcon remove firefox

Mais PackageKit c’est aussi l’outil qui sait mettre à jour votre système.

pkcon get-updates

Obtention des mises à jour   [=========================]         
Attente dans la file          [=========================]         
Démarrage                    [=========================]         
Terminé                      [=========================]         
Disponible  	act-cli-0.2.61-1.fc39.x86_64 (copr:copr.fedorainfracloud.org:rubemlrm:act-cli)	Run your github workflows locally
Amélioration	alsa-sof-firmware-2024.03-2.fc39.noarch (updates)           	Firmware and topology files for Sound Open Firmware project
Bug fix     	amd-gpu-firmware-20240410-1.fc39.noarch (updates)           	Firmware for AMD GPUs
Bug fix     	amd-ucode-firmware-20240410-1.fc39.noarch (updates)         	Microcode updates for AMD CPUs
Normale     	annobin-docs-12.46-1.fc39.noarch (updates)                  	Documentation and shell scripts for use with annobin
Normale     	annobin-plugin-gcc-12.46-1.fc39.x86_64 (updates)            	annobin gcc plugin
Bug fix     	atheros-firmware-20240410-1.fc39.noarch (updates)           	Firmware for Qualcomm Atheros WiFi/Bluetooth adapters
Amélioration	b43-fwcutter-019-36.fc39.x86_64 (updates)                   	Firmware extraction tool for Broadcom wireless driver
Bug fix     	bluez-5.73-3.fc39.x86_64 (updates)                          	Bluetooth utilities
Bug fix     	bluez-cups-5.73-3.fc39.x86_64 (updates)                     	CUPS printer backend for Bluetooth printers
Bug fix     	bluez-libs-5.73-3.fc39.i686 (updates)                       	Libraries for use in Bluetooth applications
Bug fix     	bluez-libs-5.73-3.fc39.x86_64 (updates)                     	Libraries for use in Bluetooth applications
Bug fix     	bluez-obexd-5.73-3.fc39.x86_64 (updates)                    	Object Exchange daemon for sharing content
#...
#...

Et par conséquent, la commande pkcon update va mettre à jour les paquets. Voilà, simple, efficace, et “universel”.

Je vous invite à lire la documentation pour plus d’informations.

Mais ça marche comment ?

PackageKit utilise des “backends” pour communiquer avec les gestionnaires de paquets. Un “daemon” nommé packagekitd tourne en tâche de fond le temps nécessaire à la recherche et à l’installation et des “backends” sont utilisés pour communiquer avec les gestionnaires de paquets.

Par exemple, le backend dnf pour Fedora, le backend apt pour Debian, le backend zypp pour openSUSE, etc.

Pour les développeurs, sachez que vous pouvez communiquer avec PackageKit via D-Bus, et que vous pouvez utiliser des bindings pour Python, C, Go, etc.

C’est donc un système très modulaire, et qui permet de gérer les paquets de manière uniforme quelle que soit la distribution Linux utilisée.

Mais, le revers de la médaille, c’est justement que cela utiliser D-Bus, donc que ce n’est pas viable pour, par exemple, des conteneurs ou des images OCI (Docker, Podman…). C’est un outil “haut niveau” pour des utilisateurs finaux.

Par exemple, dans un conteneur, voilà ce qu’il se passe :

$ pkcon install firefox
Failed to contact PackageKit: Could not connect: No such file or directory

Vraiment, je vais vous le répéter, pkcon, c’est pour vos postes de travail, pas pour vos serveurs ou vos conteneurs.

Mais, soyons honnêtes, vous, moi, on est des utilisateurs finaux, non ? Qu’on soit développeur, administrateur système, gamer, utilisateur bureautique, on est des utilisateurs finaux.

Donc, personnellement, je commence à prendre l’habitude d’utiliser pkcon dans mes scripts d’installation si, et seulement si, on parle de script pour des utilisateurs finaux.

Mais du coup, on remplace tout par pkcon ?

Alors non.

Déjà, comme je vous l’ai dit, cela ne marche pas sur des conteneurs (et tant mieux hein, on ne va pas démarrer un D-Bus pour installer des packages !).

Ensuite, PackageKit n’a pas toutes les options des gestionnaires de paquets.

C’est, pour le moment, une commande pratique et un backend pour des outils graphiques. C’est donc très sympa pour généraliser l’installation d’outils si vous visez plusieurs utilisateurs sur plusieurs distributions. Voire pour FreeBSD. C’est aussi super bien si vous créer un outil de gestion d’installation, vous vous connectez au D-Bus et vous installez le nécessaire.

Donc, amis développeurs qui créent des “wizzard” d’installation, il serait temps d’arrêter de faire des apt dans un processus - ça fait péter un câble aux utilisateurs de Fedora, ArchLinux, openSUSE, etc.

Cependant, les gestionnaires de paquets propres aux distributions ont bien plus d’options, des sources de packages parfois spécifiques et des fonctionnalités qui ne sont pas disponibles via PackageKit. Donc, si vous avez besoin de fonctionnalités spécifiques, ou si vous avez besoin de gérer des paquets spécifiques à une distribution, vous devrez utiliser les commandes spécifiques à la distribution.

Vraiment, PackageKit c’est pour simplifier et généraliser, pas pour remplacer.

Au final

Bien que ce soit un outil pour simplifier l’installation et qui n’a pas la finesse du “vrai” gestionnaire de paquet utilisé en direct, je commence à pousser son utilisation dans mes Makefile, scripts d’installation, articles, etc.

Pour deux raisons :

• je n’aime pas utiliser sudo dans un Makefile, je préfère l’interface proposée par PackageKit qui explique à l’utilisateur ce qu’il va se passer
• je veux me soulager de la charge de devoir proposer des commandes pour chaque distribution Linux
• je pense que c’est potentiellement plus adapté si la cible est un utilisateur final, même dans un terminal

On devrait toujours avoir le réflexe de parler de pkcon avant de parler de parler des outils spécifiques à une distribution. J’ai un avis vraiment à contre-courant de beaucoup de spécialistes, et je l’assume complètement. Je sais, et je l’ai dit juste avant, que dnf ou apt (pour ne citer qu’eux) sont des bien meilleurs outils d’installation. Je le répète donc, une fois de plus, PackageKit c’est pour simplifier et généraliser. Je le propose(rai) dans mes articles pour éviter de discriminer les utilisateurs de distributions Linux. Et je vous invite à en faire autant.

Mais, il est évident que, quotidiennement, j’utilise dnf sur mes postes Fedora, et que apt, apk, etc. sur les autres distributions que j’utilise essentiellement dans des conteneurs ou sur les serveurs au travail (ouais, pas moyen de faire plier les admins systèmes, ils veulent du Debian 😦).