Bonjour,

Je ne sais pas si je l'ai déjà dit, mais je projette dans un avenir assez proche de reconstruire tous les paquets de Logram. Non, pas les refaire, simplement les reconstruire et corriger des erreurs.

En effet, j'étais allé un peu vite et certains paquets sont loin d'être parfaits. Qt n'a pas de dépendances à la construction, les paquets Xorg ont des version totalement tordues, des paquets sont périmés, d'autres mal compilés, etc.

Avant de me lancer là-dedans, j'avais prévu une belle amélioration de l'infrastructure de création des paquets. C'est ainsi que le serveur de compilation est arrivé, permettant de créer les paquets dans un environnement contrôlé.

Il ne manque à ce serveur plus qu'une fonctionnalité, la reconstruction des paquets dépendant d'un autre quand ce dernier est reconstruit, et il sera enfin prêt pour le test grandeur nature.

Support des plugins pour Setup

Setup, quant à lui, bénéficie aussi de ces changements. Tout d'abord, pas mal de bugs et de memleaks ont été corrigés. Ensuite, une nouvelle fonctionnalité fait son apparition.

Le but était de fournir un moyen à l'empaqueteur pour dire à Setup qu'il doit trouver lui-même les dépendances d'un paquet binaire. Debian appelle cela les «shlibdeps», les dépendances trouvées automatiquement en fonction des informations contenues dans les fichiers ELF (exécutables, bibliopthèques) des paquets.

Je voulais donc que Setup contienne une fonction de la sortie. J'ai donc fait quelques adaptations (dont le support propre des versions de développement ), et j'en ai conclu qu'un système de plugins était la meilleure méthode à utiliser.

PackageSource, la partie de Setup s'occupant de la création des paquets, supporte maintenant les plugins. Pour l'empaqueteur, c'est extrêmement simple. Un ensemble de plugins (trouvés dans /usr/lib/lgrpkg) sont lancés sur chaque paquet binaire et sur le paquet source. Ils disposent de la liste des fichiers du paquet, et également de tout le document XML. Ils peuvent ainsi tout faire, y compris ajouter des paquets binaires, en supprimer, ajouter ou supprimer des fichiers au paquet, gérer le changelog, recompiler le paquet (sachant que l'infrastructure de Setup leur est disponible), etc.

C'est d'ailleurs pour cette profusion de fonctionnalités que j'ai décidé de supporter ces plugins en C++, et non en Shell ou Javascript. Ils sont rapides, peuvent bénéficier de la puissance de Qt, s'intègrent parfaitement à Setup, etc.

Il existe à ce jour 3 plugins : 2 petits et un gros :

• noinfodir s'occupe de prévenir si le fichier /usr/share/info/dir est trouvé. Ce fichier est installé par le make install de la plupart des paquets, mais n'a rien à faire dans le paquet (il est généré pour tous les paquets par le hook update-info).
• filemanypackages prévient quand un fichier se trouve dans plusieurs paquets (ou plusieurs fois dans un paquet, oui oui c'est possible ).
• shlibdeps reprend le nom Debian, et insère des dépendances pour les paquets nécessaires au chargement de tous les fichiers ELF du paquet binaire.

Les deux premiers plugins sont activés par défaut, le dernier doit s'activer pour chaque paquet binaire souhaitant l'utiliser (il est un peu lent). Pour cela :

1

<plugin name="shlibdeps" enable="true" />

Mettre enable à false permet de désactiver un plugin activé par défaut. Il est alors possible de finement contrôler les vérifications faites par Setup.

D'ailleurs, un système de «Remarques» a été ajouté à Setup. Lors de la construction d'un paquet, il est possible d'ajouter des remarques. Elles peuvent être une erreur, une attention ou une simple information. D'ailleurs, le serveur de compilation gère l'état «compilation automatique réussie avec remarques», qui permet de gérer tout ça.

Les plugins sont donc libre d'ajouter des remarques, et ils le font tous. Voici par exemple la sortie de la construction d'une version de XTerm légèrement transformée pour générer le plus de remarques possibles :

Vous pouvez constater que le plugin «noinfodir» profite du fait qu'il peut modifier la liste des fichiers inclus dans un paquet. Il supprime en effet le fichier /usr/share/info/dir, ce qui permet d'avoir un paquet propre malgré la remarque.

Le fichier metadata.xml est correctement transformé et contient à la fin de la procédure ce morceau :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<package section="x11" arch="any" name="xterm">
    <depend string="libice6>=libICE-1.0.6~2" type="depend"/>
    <depend string="libxt6>=libX1.0.7~2" type="depend"/>
    <depend string="libxmu6>=libX1.0.5~2" type="depend"/>
    <depend string="libx11-6>=1.3.2~2" type="depend"/>
    <depend string="libfontconfig1>=2.8.0~2" type="depend"/>
    <depend string="libncurses5>=5.7~2" type="depend"/>
    <depend string="libxaw7>=libX1.0.7~2" type="depend"/>
    <depend string="libxft2>=libX2.1.14~2" type="depend"/>
    <depend string="libc6>=2.11.1~2" type="depend"/>
    <files pattern="*"/>
    <plugin enable="true" name="shlibdeps"/>
</package>

Les versions bizares contenant le nom de la source sont normales (enfin...), compte tenu de la remarque en haut de news : les paquets sont cassés. L'important est que les noms sont bons.

Utilité

Outre le fait que le développeur a moins de travail, c'est surtout une question de construction automatique.

Exemple concret : OpenSSL est passé de version 0.9 à 1.0. Leur paquet a changé, de libopenssl0 à libopenssl1 (sombre histoire de SONAME, il faut ajouter ce nombre à la fin du nom de paquet, ça permet par exemple d'avoir libqt3 et libqt4 d'installés en même temps).

Le fichier de développement, libopenssl-dev, n'a pas changé, donc la construction a marché. Seulement, dans les fichiers ELF, c'est libopenssl.so.1 qui est demandé, et non libopenssl.so.0, du fait du changement de version (ouais, là ils ont fait un sale coup à OpenSSL, pensez à Debian qui doit recompiler plus de 1000 paquets ).

Bref, grâce aux dépendances automatiques, le paquet construit automatiquement marche à la perfection du premier coup, et il ne faut pas un packageur pour manuellement changer la version d'OpenSSL voulue.

Ça permet également de s'assurer qu'un paquet sera lancé en utilisant une version plus récente ou égale à la version de la bibliothèque l'ayant construit, ce qui évite également les petits plantages bizares (quand une application plante au démarrage), et très gênants pour l'utilisateur qui est pris au dépourvu.

Bonne chose donc .