Cette semaine, nous avons concocté une potion à partir de quelques ingrédients fournis par notre brillante équipe de développeurs et des empaqueteurs.
La façon dont les applications sont gérées et empaquetées dans Mageia, comparée à celles de nos concurrents, simplifie la gestion du système et l’utilisation des logiciels. Le Centre de Contrôle de Mageia (CCM) et ses outils graphiques sont un élément majeur de Mageia. Ce qui est par contre largement méconnu, c’est comment, (comparée à d’autres systèmes) les applications sont empaquetées. La manière dont les greffons et les compléments logiciels sont gérés, et comment les dépendances sont prises en compte au cours du processus d’empaquetage.
Allons-y !
Principes conceptuels
Mageia a hérité et perfectionné la philosophie d’empaquetage de Mandriva/Mandrake ; notre objectif est de livrer des applications « clé en main », sans pour autant mégoter sur les fonctionnalités optionnelles ou les modules complémentaires. D’autres distributions tendent à packager les applications dans leur version la plus légère, écartant plugins et add-ons, qui amène l’utilisateur à installer des extras. Dans Mageia, plugins, intégrations et support multimédia sont souvent directement inclus dans l’application ou dans un unique méta-paquetage.
Mageia se distingue par une philosophie d’empaquetage intégrée : plutôt que de fractionner un programme en de multiples sous-paquets ou d’imposer des restrictions de licence strictes dans le dépôt principal, les mainteneurs de Mageia compilent les logiciels en activant par défaut autant d’extensions, de filtres et de fonctionnalités de prise en charge matérielle que possible, pourvu qu’ils apportent des fonctionnalités supplémentaires à l’application et soient approuvés par l’équipe d’empaquetage.
| Fonctionnalités | Mageia | Autres distros |
|---|---|---|
| Centre de Contrôle de Mageia | ![]() ![]() ![]() | Des équivalent chez quelques unes |
| Famille DrakTools | ![]() ![]() ![]() | Peu commun |
| URPMI/URPM* | ![]() ![]() ![]() | Propriété de l’écosystème Mageia/Mandriva |
| rpmdrake | ![]() ![]() ![]() | Peu commun |
| MSEC | ![]() ![]() ![]() | Système propriétaire |
| DrakGuard | ![]() ![]() ![]() | Des alternatives existent |
| UserDrake | ![]() ![]() ![]() | Des équivalents existent |
| Server Wizards | ![]() ![]() ![]() | Des alternatives existent |
| Gestion graphique centralisée | ![]() ![]() ![]() | openSUSE avec YaST |
| RPM | ![]() | Fedora/openSUSE |
| DNF | ![]() | Fedora essentiellement |
| GNOME/KDE | ![]() | Plusieurs distros |
| systemd | ![]() | Plusieurs distros |
Notre installateur
Dans Mageia 10, nous avons actuellement URPMI (User RPM Installer), qui est notre gestionnaire de paquets par défaut et l’épine dorsale de l’installation. Il prend aussi bien en charge l’installation en mode graphique qu’en ligne de commandes. Une prise en charge de DNF (maintenant DNF5) est également incluse.
URPMI a de nombreux avantages sur ses concurrents, comme :
- L’utilisation des résumés très légers des données essentielles à la résolution des dépendances. Cette propriété permet d’interroger ou d’actualiser les dépôts presque instantanément, même sur des connexions lentes ;
- L’économie d’espace disque : tant que ce n’est pas nécessaire, il se dispense de stocker localement la description complète et les informations de chaque paquet ;
- Le moteur commun à la ligne de commande et au gestionnaire graphique: En effet rpmdrake le gestionnaire graphique d’installation des paquets partage utilise URPMI. Dans d’autres gestionnaires, les outils graphiques agissent comme des coquilles indépendantes qui parfois entrent en conflit ou ne reflètent pas les mêmes statuts des paquets orphelins ;
- Enfin, URPMI a peaufiné durant des décennies ses algorithmes de détection de paquets orphelins après la désinstallation d’une application, l’adaptant à la structure des paquets de Mageia ; cela empêche la désinstallation par erreur de bibliothèques système critiques lors d’opération de nettoyage.
DNF a également été porté dans Mageia en raison d’un certain nombre de fonctionnalités modernes :
- Historique des transactions.
- Modules et AppStream. Une meilleure intégration avec les dépôts de logiciels modernes.
- Support actif en amont. Il est géré directement par le projet rpm.org.
Quelques commandes urpm* dans le terminal :
- urpme : désinstaller des paquets,
- urpmq : lister des paquets,
- urpmf : rechercher des paquets contenant des fichiers ou des fonctionnalités spécifiques,
- urpmi : installations et mises à jour.
Un petit schéma

Chez Mageia, nous concevons, dans nos dépôts, des versions de logiciels compilées dès le départ avec la prise en charge activée pour — par exemple — tous les modules réseau, les protocoles de streaming et l’accélération matérielle vidéo, de même pour de nombreux formats d’image propriétaires ou peu usités que d’autres distributions déposent sur des dépôts secondaires ou plus simplement suppriment.
Dès qu’un ajout rend l’application empaquetée plus utile, le bénéfice pour l’utilisateur final prime sur une stricte « pureté » de l’empaquetage. Ce qui explique en grande partie l’existence des dépôts officiels « Tainted » (dédiés aux logiciels soumis à des brevets ou à des restrictions légales dans certains pays), qui permettent de proposer les applications dans leur version intégrale sans en restreindre les fonctionnalités.
Mageia gère l’infrastructure de construction, les dépendances, les politiques et les contrôles pour garantir que les paquets forment un système cohérent.
Le paquetage « gimp-plugin-astronomy », qui restait disponible jusqu’à la fin du support de Mageia 9, en est un exemple patent. Bien que plus supporté par ses concepteurs, Mageia a continué à le proposer à ses utilisateurs jusqu’à la version GIMP 3.0, avec laquelle il n’est plus compatible suite au passage de GIMP à Python 3.
Quelques autres exemples :
- LibreOffice. Dans d’autres distributions, il est empaqueté sous forme de composants distincts, et des fonctionnalités comme les thèmes d’icônes, l’intégration de base de données ou les environnements de bureau sont omis.
- Inkscape. Dans Mageia, il intègre une carte de dépendance qui permet, par défaut, toutes les extensions pour le rendu mathématique, le traitement bitmap (image matricielle ?) et l’importation/exportation de fichiers CAO, ne nécessitant pas la recherche d’autres bibliothèques Python.
- Audacity, VLC, Kodi. Grâce aux différents dépôts, ils sont empaquetés avec la prise en charge activée de fonctionnalités n’apparaissant pas dans d’autres distributions.
- Pidgin. Nous avons déjà présenté cette application ici même. Ce paquet de Mageia est très complet, comportant de nombreux greffons et protocoles de messagerie que l’on ne trouve pas dans d’autres distributions.
Un aperçu de l’empaquetage dans Mageia
| N° | Phase | Action | Décision | Résulat |
|---|---|---|---|---|
| 1 | Source | Obtenir le code source | − | Disponible |
| 2 | Licence | Vérifier la licence | Valable ? | Oui |
| 3 | Dépendances | Déterminer les dépendances | Disponible ? | Oui |
| 4 | .spec | Créer le fichier .spec | Correct? | Prêt |
| 5 | Construction | Construire le paquet RPM | Construction réussie? | RPM créé |
| 6 | Installation | Installer le paquet | Installation correcte? | Installé |
| 7 | Tester | Lancer et tester l’application | Fonctionne correctement ? | Réussite |
| 8 | Revoir | Tester fichiers et dépendances | Des erreurs ? | Révision |
| 9 | Correction | Réparer .spec ou paquet | Reconstruire ? | Retour en 5 |
| 10 | Validation | Soumettre à évaluation | Validation ? | Approuvé |
| 11 | Publication | Publier sur les dépôts | − | Disponible |
Quelques caractéristiques de notre empaquetage :
- Python. Conventions claires (explicites, intelligibles), pyproject, noarch, documentation et dépendances gérées par RPM
- Java. Nous évitons les dépendances JAR redondantes et préservons la séparation des composants.
- Firefox. Paquet principal et traductions séparées. La langue requise est installée en fonction de la langue du système.
- LibreOffice. Installation de la suite complète et de la langue requise en fonction de la langue du système, dans un méta-paquet unique, ou installation séparée des applications individuelles.
- Bibliothèques. Runtime, développement et dépendances sont séparées.
- KDE/Applications Qt.
- Licences. Nous établissons la séparation des licences via les dépôts « Core/Nonfree/Tainted ».
- Mises à jour validées par l’équipe QA avant l’ajout à la version stable.
Quelles conséquences pour l’utilisateur
La plupart de ces choix ne se voient, à l’écran. À eux seuls, ils n’améliorent pas les animations de Plasma, ni la rapidité de Firefox.
Leurs intérêts apparaissent plutôt dans des situations quotidiennes.
- Installer une application et ses dépendances.
- La désinstaller sans laisser de fichiers résiduels.
- Mettre à jour une bibliothèque sans se retrouver avec plusieurs copies incompatibles.
- Installer les seules langues dont nous avons besoin.
- Installer les seules documentations qui nous intéressent.
- Avoir des paquets de développement à part.
- Maintenir une base cohérente de logiciels.
- Recevoir des mises à jour passées par un processus de validation.
En d’autres mots, nos utilisateurs n’ont pas à s’inquiéter de l’empaquetage. Si le boulot est fait correctement, ça marche.
Conclusions
La force principale de notre empaquetage repose sur la coopération de toutes nos équipes pour que chaque programme s’intègre correctement au système.
Les règles d’empaquetage, la séparation des composants, la gestion des dépendances, la gestion rigoureuse des bibliothèques tierces, la gestion des licences et le processus de contrôle qualité forment un système intégré et cohérent.
Le travail fourni par nos équipes d’empaquetage, de développement et d’assurance qualité, bien qu’invisible pour nos utilisateurs ou le grand public, est l’un des facteurs clés qui font de notre distribution une solution Linux véritablement stable et fiable. Un travail d’ingénierie considérable est nécessaire pour assurer la cohérence de l’ensemble et aboutir au résultat final.



































