Salut journal,

On parle assez souvent ici des packages managers (ou gestionnaires de paquets), pour la bien simple raison que c'est une partie centrale de l'OS, et qu'il est différent suivant la distribution utilisée. Les trolls s'en donne donc à coeur joie pour le plus grand plaisir des moules linusfriesques.

Cependant, on parle de quelques nouveautés, on parle des limites ou des problèmes rencontrés, on apt get à tout va pour descendre RPM ou vis-versa, on obtient parfois quelques petites infos intéressantes, mais on a jamais une vue globale de ce qui se passe dans le monde des packages managers.

C'est pourquoi je me suis mis en quête de m'informer par-ci par-là, d'appronfondir quelques sujets qui ont alléché mon navigateur oueb. Et c'est pourquoi, journal, je t'en fais profiter, en espérant en apprendre un peu plus de la part des lecteurs DLFP, qui me corrigeront sans doute, qui donneront quelques infos sur comment ça marche sur leur distrib préférée ou comment ça devrait marcher selon eux, et que trolleront à coeur joie pour le plus grand plaisir des moules.

J'aborderais donc toutes une panoplies de sujets, tous liés plus ou moins au package management, si hype dans le monde unix. J'aborderais quelques situations pratiques et nouveaux projets rencontrés via la distribution que j'utilise le plus, openSUSE, distribution relativement peu utilisé dans le monde francophone pour une foule de raison (concurrence historique de Mandrake, accord MS Novell, succès d'Ubuntu, souvenirs d'Alsace et Lorraine, ..). Cette distribution est néanmoins assez populaire en Europe du Nord, un peu de l'Est, en Italie, .. et en Allemagne, bien sûr (comme ça vous êtes prévenus :) )

Voici un rapide aperçu du contenu :
- évolution du package management
- création de paquets
- gestion des mirroirs
- unification des systèmes

Dans un autre journal, je me pencherai sur les algorithmes de résolution de dépendances. Cette partie étant relativement longue et très intéressante, j'en dédierai un journal complet.


Evolution du package management (ou le rpmdeb sapien sapien)
---------------------------------------------
Le package management sous Linux semble avoir évolué passablement au cours du temps, connaissant différentes évolutions que l'on peut qualifier de "générations"[1] :

Génération 0 - Pas de package management du tout. L'utilisateur place les fichiers individuels, là où il faut sur son système pour que ça marche.

Génération 1 - Les différents programmes sont empaquetés pour faciliter l'installation sur le système cible. L'utilisateur n'a qu'à extraire ou exécuter le paquet, mais il n'y a pas de vérification des dépendances.
S'il manque une librairie requise par le programme, il ne fonctionnera pas correctement. Exemples : La plupart des installateurs windows, de simples fichiers zip, les paquets slackware.

Génération 2 - Construite sur la génération 1, en ajoutant le support des dépendances/pré-requis. L'utilisateur connait ainsi ce qu'il doit installer avant de pouvoir installer son programme favori. Exemples : fichiers MSI, dpkg, rpm.

Génération 3 - Construite sur la génération 2, en ajoutant la résolution automatique des dépendances, à partir d'une sources de logiciels. Tous les paquets susceptibles d'être nécessaire à un programme sont directement disponibles. Exemple : apt, up2date, redcarpet, yum, urpmi, yast.

Cette génération 3 existe depuis un certains temps, et est largement utilisée dans presque toutes les distributions. Peut être est ce que le summum du package management est atteint... Peut être pas.
Cette 3e génération n'est pas sans défauts :

- Les "bonnes" sources du package manager doivent être configurés, parce qu'elles ne sont pas toujours activées par défaut, pour des raisons légales, à cause de la politique de la distribution, ou parce que le dernier logiciel top-moumoutte n'est pas dans les dépots officiels, mais directement sur le créateur du le-dit logiciel top-moumoutte. L'utilisateur devra donc chercher l'URL du dépot, trouver le fichier ou le programme dans son centre de contrôle pour ajouter ce dépot, puis enfin, pouvoir installer son logiciel. Beaucoup de chose pour un simple logiciel ? Pas pour les geeks de DLFP. Enfin, peut que si.

- L'utilisateur débutant doit apprendre à manier un front end pour son package manager, Le design de ceux-ci varie grandement, mais le premier réflexe de l'utilisateur windowsien reste sans appel : Il veut double clicker sur son fichier d'installation, et clicker sur "Suivant".

> One-Click-Install (OCI)

openSUSE (je vous avais prévenu :) ) a introduis la technologie "One-Click-Install" dans le courant 2007, rétroactivement pour la version 10.2 (sortie en décembre 06), et de base dans la dernière version 10.3 (octobre 07).
Un simple clic sur un lien web, et le package manager se lance et permet, après le mot de passe root, de cliquer sur "suivant" d'ajouter le dépot, le rafraichir, télécharger le logiciel et ses dependances, puis l'installer. A noter que OCI est le fruit d'un programmeur indépendant, et non des ingéneiurs de SuSE/Novell.

OCI porte mal son nom... puisqu'on est loin du simple clic pour l'installation d'un logiciel (4 ou 5 mini, plus le mot de passe root). Et encore heureux. En effet, le vice de cette facilité d'ajouter des dépôts et packages est.. sa facilité, justement. Facile d'ajouter un malware verreux en modifiant un simple lien sur le wiki officiel, par exemple. Le problème de la sécurité des dépôts apparaît, ou du moins, il devient plus dangereux pour un utilisateur non expérimenté d'être la victime d'une éventuelle "attaque".

Si le problème ne s'est pas (encore) présenté, c'est sans doute grâce à plusieurs facteurs :
- Le dépot doit être validé par un clé GPG. Je doute que ce soit suffisant pour éviter qu'un débutant n'installe n'importe quoi.
- Un changement sur le wiki openSUSE ne passerait pas inaperçu, et serait corrigé de suite.
- La "websphère" de la distribution est assez limitée: très peu de dépôts sont situés en dehors du Build Service openSUSE (uniquement ceux qui ne peuvent y être pour raison légale - VideoLan, Packman, .. d'autres?), le blog des développeurs planetsuse.org. La plupart des liens OCI sont "sous contrôle".

Mais c'est insuffisant. Des solutions pour "sécuriser" le système (ou le comportement chaise/clavier, plutôt) sont étudiées. Un système de confiance donné par vote (trust rating) sera donné à chaque dépot du BuildService openSUSE. C'est un premier pas, même si je ne suis personnelement pas convaincu de l'efficacité du système.

> Mon expérience :

En quelques semaines, l'environnement openSUSE change : Les liens 1-click-install profusionnent sur le wiki, l'aide sur les canaux IRC est transformé : un simple !command et le bot IRC crache le bon lien pour installer le tout dernier compiz-fusion-gl-etreme-mod-crystal-top-moumoutte. Le package manager devient beaucoup plus transparent, plus invisible à l'utilisateur final. Les débutants sont comblés. Et les habitués aussi.
Les bénéfices, pour une distribution grand public sont conséquent et je pense que cette pratique sera étendue à la plupart des distributions.

La technologie OCI continue d'évoluer, avec des variantes en consoles, des interfaces graphiques pour créer des lien OCI, la génération automatique des ces liens à partir d'une liste prédéfinie, l'utilisation généralisé dans les moteurs de recherche de paquets openSUSE [3][4] et dans le futur Software Portail Communautaire [5].

Création de paquets (ou comment emballer le chocolat dans le papier d'alu)
--------------------------
Un autre sujet récurrent dans les journaux des moules est la création de package. En effet, s'il existe différents formats (deb, rpm, tgz, .. ), un même format est souvent incompatible entre distributions, et les paquets d'une version d'une distribution est plus ou moins incompatible avec la version suivante ou antérieure.

Cette situation conduit le créateur d'un programme, qui désire diffuser son travail, à différentes options :
- trouver et faire appel à un packager pour chacune des distributions. Avec bien sur aucune assurance sur l'efficacité et le suivi de celui-ci sur son projet et ses mises à jour.
- créer lui-même moultes versions de son programme top-moumoutte, une pour chaque distribution (du moins les principales). Outre le fait qu'il devra se familiariser avec les différentes procédures deb, rpm, archbuild, et autres, il devra tenir ces paquets à jour avec les toutes nouvelles versions de son programmes.
- ne rien faire, et laisser les sources de son programme en tar.gz sur son site oueb. Peut être pas la meilleure solution pour faire connaître son top moumoute de programme ré-vo-lu-tionaire.

> les solutions décentralisées

Une solution originale qui a émergée sont les package manager décentralisés, qui permettent de creer un seul et unique paquet qui s'installera sur chaque distribution. Un article général présentant bien le concept, écrit par l'auteur de ZeroInstall l'année passée, et avec tout plein de beau schéma est disponible ici [6].

L'article pointe du doigt les effets "pervers" du cloisonnement du système de chaque distribution, et les défis rencontrés par les packages manager décentralisés. Il est relativement technique, mais très intéressant pour qui veux comprendre le fonctionnement de klik, autopackage et autre ZeroInstall.

Concrètement, le principe utilisé est similaire à la manière windowsienne de procédé : Après l'installation d'un client, on peut télécharger des paquets indépendants (comme un exe) ou un fichier pointant vers des repo online (à la manière OCI présentée ci-dessus). On clique et le paquet s'installe (télécharge et installe les dépendances) avec ses librairies statistiquement liés dans /home. Certains vont plus loin, en utilisant les librairies dynamiques du système si elles sont détectées sur le système cible, ou essai même d'intéragir avec le package manager en place pour éviter les doublons de programmes.

Les inconvénients de cette méthode sont bien sur ces librairies statiques, à contre courant du principe meme du package management, la non utilisation de dépots centralisés si pratique, et cette impression d'installer (ou ne pas installer justement) un paquet non géré par ce bon vieux package manager. Mais force est de constater qu'il y a des progrès et que la marge de progression est grande.

> openSUSE Build Service (oBS)

L'openSUSE Build Service[7], lui, reste dans la philosophie traditionnel des systèmes centralisé. Son utilisation primaire est de fournir une grande variétés de paquets pour les distributions openSUSE, des nouvelles versions de paquets de divers projets (KDE4, ..), des paquets "third-party" et des backports pour les différentes versions stables de la distribution. Il est assez similaire au système de build public de Fedora.

L'infrastructure permet ainsi de compiler les paquets à distance, dans une machine virtuelle Xen lancé par le packager via une interface web ou un client en ligne de commande. Toute l'infrastructure du Build Service tourne sur plus d'une centaine de machines généreusement données par AMD au projet openSUSE, et le code du Build Service est disponible librement. A noter que la version de développement openSUSE est désormais construite dans le Build Server.

Là où c'est intéressant pour un packager, c'est que le Build Service permet, simplement à tout un chacun, de créer des paquets pour différentes distributions, à partir d'un unique fichier de configuration (.spec file). La gestion des doits est bien sûr gérée, de sorte que plusieurs personnes peuvent s'occuper d'un certain projet.

Le Build Service a de multiples avantages :
- Il resoud automatiquement les dépendances des paquets compilés. Ainsi, si un paquet B dépend d'un autre paquet A, le paquet B va être automatiquement recompilé si la dépendance A est modifiée et recompilée. On a ainsi l'assurance que ce paquet va bel et bien être compatible avec une certaine version d'une distribution.
- Il permet de lier des projets entre eux. Ainsi, un patch peut être avec la nouvelle version d'un autre projet. Un développeur qui créer un patch pour Amarok dans son environnement local (compte du build service) peut le tester dans un environnement différent que le sien. En liant son amarok patché au projet KDE, il a l'assurance que sa version patchée d'amarok sera recompilé lorsque le projet KDE sera recompilé.
- Il permet de compiler pour de multiple distributions, à partir d'un seul fichier de configuration (.spec). Actuellement, les distributions supportées sont SUSE Enterprise et openSUSE (10.1, 10.2, 10.3, Factory, SLE 9 et 10), Fedora (6, 7, 8) et RH Enterprise (RHE 5, Centos 5), Mandriva (2006, 2007 et 2008), Debian etch et xUbuntu (6.04, 7.04, 7.10).
- Enfin, le build service est synchronisé sur plusieurs miroirs, la disponibilité des paquets est garantie en tous temps.

Le système n'est pas parfait, parfois les paquets ne compilent pas (des outils de monitoring via l'interface sont là pour aider à déterminer ce qui ne va pas et ce qui doit être changé dans le fichier .spec du paquet), et toutes les distribtions ne sont pas prises en compte, mais c'est un premier pas vers un système de build qui n'est pas entièrement spécifique à une distribution.

Un utilisateur Fedora a testé l'infrastructure oBS l'année passée, vous pouvez lire son retour d'expérience ici [8]

> Mon expérience

Ben j'suis une daube en packaging, mais c'est pas le sujet :).L'interface est agréable et intuitive, et quelques changement sont prévu prochainement pour encore l'améliorer. Le client CLI semble efficace, mais j'ai pas vraiment poussé plus loin. A voir pour les packagers en herbe...
Quelques statistiques au passage :

A la semaine du 5 mars, le Build Service contenait 2035 (+50 par rapport à la semaine précédente) projets, 34531 (+145) packages, 4751 (+122) dépôts par 4575 (+129) utilisateurs confirmés.

Il faut bien sur modérer le nombre de paquets, puisque il y a plusieurs architectures, pour plusieurs distributions, et que parfois un seul paquet sources peut produire plusieurs paquets binaires.


Gestion des mirroirs (ou savoir qui est le plus beau)
------------------------

Il y a une chose qui m'a toujours déça lorsque j'utilisais mon package manager finement configuré : Le mirroir que j'avais entré était momentanément mort, et précisément à l'instant où j'en avais crucialement besoin :)
La parade consistait donc
- à chercher sur le wiki la liste des miroirs officiels
- à entrer auparavant plusieurs miroirs pour chaque source, fonctionnalité prise en charge par bon nombre de package managers.

Il faut donc contourner le problème d'indisponibilité momentanée, du coté client. Et pourquoi pas côté serveur ?

Voyons ce que contient les serveurs openSUSE[9] :
distribution openSUSE 10.1, 10.2, 10.3, snapshots unstable (alpha et beta)
3 architectures, les sources, les paquets debuginfos, les branches de test, les branches drpmsync, et bien sûr, les dépots du Build Service.

Combien cela répresente-il ?
- Plus de 700'000 fichiers dans la branche openSUSE :

/distribution: 289794
/update: 14896 (seulement 10.3)
/repositories: 413142

Taille totale : 864 Go (état début mars), 15'000'000 à 40'000'000 de requêtes HTTP par jour.

Une sacrée charge. Existe-t-il un serveur avec une telle capacité ?
En comparaison, un mirroir ubuntu entier (incluant ISO) pèse ~ 260Go, debian (sans ISO) pèse ~320Go (le nombre de requêtes journalière doit être bien plus élevée cependant)

Et c'est là que les mirroirs viennent à la rescousse.
Est-ce que tous les mirroirs openSUSE sont égaux ? Dans le temps pré-Novell, oui. Il n'y avait pas autant de paquets disponibles pour la distribution. Mais depuis l'ouverture de la distribution, chaque mirroir n'a pas forcément le même contenu que son voisin (limitations de capacité).
Effectivement, avec la taille nécessaire pour acceuillir le contenu total des FTPs, il n'y a _plus_ de mirroirs complets.
Certains ne mettent à disposition que la dernière release (10.3), d'autres seuelement les repos du Build Service. D'autres ne sont peut être pas encore à jour avec les tous derniers builds.
Seuls quelques fous mettre à disposition l'ensemble du contenu (800+Go), mais les dev ont déjà du mal à trouver un mirroir pour le BuildService (+200Go). Sans compter que ce contenu change très souvent, à tel point que parfois, lorsqu'une synchronisation de tous les serveurs est terminée, le contenu à déjà changé sur les serveurs principaux !

Comment donc utiliser les mirroirs, si l'état de ceux-ci changent continuellement de complet et à jour, à incomplets et pas à jour ?

> openSUSE download redirector : mod_zrkadlo

Une solution proposée est de créer de listes dynamiques du contenu de chaque mirroir. Si on ne peut pas contrôler le contenu des mirroirs, on peut en revanche les observer.

Le choix d'un miroir est avant tout déterminé par localisation de l'IP (GeoIP), puis les choix potentiels sont analysés : le redirecteur est lié à une base de donnée SQL qui connait le contenu exact de chacun des mirroirs. Cette base de donnée est actualisée périodiquement par un scanner qui analyse tous les miroirs, et de plus un programme "ping" contrôle la réactivité du mirroir par intermittence, et peut ainsi désactiver ou mettre en pause la redirection vers un certain mirroir. Tout ca est implémenté de façon générique dans un module apache écrit en C, mod_zrkadlo[11]. Pour la petite histoire, le développeur de ce module a assister à un concert en Slovaquie d'un groupe nommé "Za Zrkadlom - behind the mirror", zrkadlo signifiant "mirroir", et il lui fallait un nom :)

Le désavantage de ce système de gestion de miroir, est qu'il doit être d'une fiabilité aboslue. Une panne du redirecteur, et c'est tout le système qui chute... Le recours manuel à la liste officielle des miroirs étant l'unique solution si le client n'implémente pas une liste de miroirs en cache (le client natif zypp n'inclut pas encore ça, mais c'est prévu). Sinon, outre la souplesse que ce système procure, il est possible de compter les téléchargements d'une manière relativement fiable.

Notons que des systèmes à peu près similaires existent déjà, et ont servi de modèles pour ce module : sourceforge, boucer (mozilla) qui est implémentée en php, Fedora MirrorManager qui est très similaire avec une approche un peu différente (évolution d'une liste statique à une liste prégénérée), qui est implémentée avec moins de granularité mais qui dispose d'une liste de secours en cas de problème, et mod_offload (icculus.org)

> Mon expérience

Ca marche au poil, même les jours de release on tombe sur un serveur rapide. Par contre, quand le RAID qui supporte le redirecteur lâche (comme à la mi-février), c'est 24h sans possibilité de faire quoique ce soit, à part utiliser manuellement un miroir qui va bien.. Pas top pour les débutants, espérons que le fallback système soit implémenté rapidement.


Unification des packages management (ou comment on les clonera tous)
-----------------------------------

Je suis tombé l'autre jour sur un blog qui m'a fait un peu sourire[12].
L'auteur proposais d'unifier les meta-packages manager (apt, yum, urpmi) au travers d'un nouveau système UPS, Unified Package Manager.
Pour unifier .deb et .rpm, l'auteur propose une nouvelle spécification UPS (Unified Package System) qui conviendrait à tous le monde, et de creer UPS, Unified Package Format.

Si l'attention est louable et que l'auteur propose une démarche pour développer ce nouveau format, je doute un peu du succès que pourrait avoir l'abandon de deb et rpm tant ils sont populaires. Cependant, si l'unification des formats ne semble pas réaliste, celui de l'unification des front-end est une voie à explorer.

> Smart PM

Smart[13] est un premier essai, développé par l'ex-mainteneur d'apt4rpm chez Connectiva (et qui travaille chez Ubuntu actuellement je crois). Smart peut être utilisé sur n'importe quel système, puisqu'il reconnait les différents dépots RPM (apt4rpm, rpm-md, red carpet, urpm, ..), deb, slackware. Si son algorithme semble un peu plus évolué et puissant que ce qui existe actuellement (je reviendrai la dessus dans un prochain journal), je n'ai pas l'impression qu'il est arrivé à détroner le package manager d'une distribution ou d'une autre, peut être à cause de son efficacité un peu trop "aggressive" (je me rappelle avoir eu pas mal de souci lors d'un dist-upgrade).

> PackageKit

Au contraire de Smart, PackageKit[14] n'est qu'une interface qui n'essai pas de réinventer la roue. Son but premier est d'unifier toutes les interfaces graphiques utilisées dans les différentes distributions, et d'utiliser les dernieres technologies pour que le processus "suck less".
Ce logiciel met a disposition une série d'abstraction D-BUS qui repose sur les différentes technologies des meta-packagers existants, et utilise ceux-ci pour la résolution des dépendances. Avec PoliceKit, il permet à l'utilisateur d'une session de manager ses paquets de façon sécurisé, grâce à une API cross distribution et cross-architecture. L'etat actuel de l'implémentation des différents backend est visible dans ce tableau[15]

PackageKit n'est pas sponsorisé, mais le projet semble intéresser Red Hat, openSUSE et surement quelques autres. Un avenir prometteur ?

Ainsi journal, je te laisse méditer sur ce (trop) long journal, et te donne rendez vous pour le prochain, qui traitera de façon pas trop superficielle les algorithmes de résolution des dépendances, les limites actuelles et peut être quelques solutions prometteuses.

Sources et info :
---------------------
[1] http://blogs.warwick.ac.uk/bweber/entry/next_generation_pack(...)
[2] http://en.opensuse.org/Meta_Packages
[3] http://software.opensuse.org/search?baseproject=openSUSE:10.(...)
[4] http://packages.opensuse-community.org/
[5] http://en.opensuse.org/Software_Portal
[6] http://osnews.com/story/16956/Decentralised-Installation-Sys(...)
[7] http://en.opensuse.org/Build_Service
[8] http://liquidat.wordpress.com/2007/07/06/using-the-opensuse-(...)
[9] http://www.poeml.de/~poeml/talks/redirector/
[10] http://en.opensuse.org/Build_Service/Redirector
[11] http://www.zrkadlo.org
[12] http://computerstuff.jdarx.info/content/unified-package-mana(...)
[13] http://labix.org/smart
[14] http://www.packagekit.org/
[15] http://www.packagekit.org/pk-faq.html

> Lire le journal (57 commentaires, moyenne: 3,1).