Bonjour ,

Aujourd'hui, j'ai une bonne nouvelle. Non, Setup beta n'est pas encore sorti, car deux fonctionnalités manquent encore, mais il y a d'autres choses intéressantes.

Tout d'abord, depuis le passage à Git, Setup a bénéficié de très grosses avancées. J'ai également eu le temps de me familiariser avec cet outil, et de créer plein de branches en local (autre trucs : git clone sur une clef USB pour rapidos sauvegarder tout son travail avec l'historique, Git <3 )

Gestion des paquets source

Dans le respect total de la GPL et dérivées, quand on fournit un binaire, il faut absolument fournir les sources. Pour fournir cette possibilité, mais également pour permettre aux utilisateurs de recompiler leurs paquets, Setup gère maintenant les paquets sources.

Un paquet source est une petite archive contenant le metadata.xml ainsi que les différents fichiers et patches nécessaires à la construction d'un paquet. Par contre, les sources n'y sont pas, le fichier metadata.xml contient simplement la méthode pour les télécharger. Ainsi, on reste à jour avec l'upstream, qui peut d'ailleurs être un dépôt constamment en mouvement, comme un dépôt Git ou Subversion.

Depuis fin décembre, début janvier (donc juste après l'alpha1), Setup sait récupérer automatiquement le paquet source d'un paquet binaire, et le placer dans le dossier courant. Il suffit alors de le désempaqueter avec tar, puis de lancer «setup binaries metadata.xml» pour obtenir un paquet recompilé. En exportant correctement différentes variables d'environnement et en modifiant le metadata.xml, il est possible de tuner le paquet pour son processeur, d'y ajouter des patches persos, de changer les options de compilation, la source du paquet, de lui supprimer des dépendances, etc.

Tagguer vos paquets devient un jeu d'enfant !

Une autre fonctionnalité, présente dans quelques autres gestionnaires de paquets, mais plus agréable dans Setup, est le tag des paquets. Ces tags peuvent venir de l'empaqueteur (intégration à KDE, si le paquet a une licence douteuse à approuver, s'il nécessite un redémarrage), ou de l'utilisateur (ne pas installer, ne pas mettre à jour, ne pas supprimer, je le veux).

Voici une description plus poussée de ces tags :

• kdeintegration : Intégration à KDE. Ce tag est le seul qui occupe deux bits, pour couvrir les valeurs de 0 à 3. Une valeur de trois correspond à une application parfaitement intégrée, généralement de KDE Software Compilation ou de KDE Extragear (exemples : Amarok, KOffice, Konqueror). Une valeur de deux est pour une application Qt ou concue pour l'intégration (exemples : Arora, OpenOffice.org). Une valeur de 1 correspond à une application GTK qui ne fait rien pour aller dans KDE (exemples : FireFox, Galéon, Nautilus, applis GNOME). Une intégration de 0 correspond à une application console, ou une application X utilisant un framework difficile à intégrer (Qt3, GTK 1, TK, etc).
• eula : Contract d'Utilisateur Final. Ce paquet contient un document que l'utilisateur doit lire et approuver avant le téléchargement du paquet (en effet, le téléchargement, dans beaucoup de licenses, accepte celle-ci). Par exemple, il faut accepter la licence Flash pour avoir Flash, la licence nVidia pour leur pilote propriétaire, etc.
• needsreboot : Nécessite un redémarrage pour fonctionner correctement. Setup ne fait qu'en avertir l'utilisateur.
• dontinstall : Paquet banni de l'installation (propriétaire, paquet qu'on n'aime pas, etc). Il fera échouer toute branche le nécessitant, ce qui peut poser problème (mais le message donné par Setup est alors très clair : «Le paquet %1 à la version %2 devait être installé mais a été tagué comme étant non-installable»).
• dontremove : Interdit la suppression du paquet.
• dontupdate : Ne pas mettre à jour. Flag intéressant car venant d'un Use Case (cas d'utilisation). Madame Michu installe un Logram, ou plutôt se le fait installer par son beau-fils. Il passe ensuite quelques heures à lui expliquer comment se servir de KDE 4.4, comment mettre à jour, aller sur le web, etc. Au fil des mois, Madame Michu s'habitue au fonctionnement de son ordinateur et commence à bien aimer. Malheureusement, 6 mois plus tard, paf, une grosse mise à jour. Madame est étonnée, mais la fait quand-même. Un redémarrage lui est demandé, elle le fait. PAF, fini ! Mais qu'est-ce donc ? Son environnement est tout chamboulé, elle se retrouve sous KDE 4.5 !! Le tag du paquet kdelibs4 en dontupdate aurait évité cette mésaventure, et Madame Michu aurait gardé son ordinateur à jour, avec les avantages du rolling release, sans les inconvénients. Elle aurait pu attendre KDE 4.6 si elle avait voulu .
• wanted : Va de paire avec la gestion des orphelins. Si vous installez le paquet A, qui installe comme dépendance B, la suppression de A entraînera la suppression de B. Malheureusement, vous vous servez peut-être de B dans un script, ou dans une utilisation graphique. Taguer B comme étant wanted garanti qu'il ne sera pas supprimé dans cette condition. D'ailleurs, tout paquet installé manuellement est ainsi tagué (donc «setup add A» tag automatiquement A comme étant voulu).

Tout ceci permet un contrôle fin des paquets. C'est une belle grosse fonctionnalité, contribuant au confort d'utilisation de Setup .

Changelog en ligne d'un paquet sur le site web

Petite amélioration de RepositoryManager et de la v4. Maintenant, quand un paquet est importé dans une distribution, son changelog est enregistré dans la base de donnée. Ainsi, il devient possible de le consulter en ligne, même sans devoir utiliser Logram. De plus, cet affichage est traduit dans la langue courante du site. Pour y accéder, allez à la page du paquet, puis cliquez sur «Modifications : Voir» dans la liste des attributs.

Détection et suppression des paquets orphelins

Logram est une distribution rolling release, ce qui veut dire qu'elle est constamment mise à jour. Cela implique deux choses. Tout d'abord, il y a beaucoup de mouvement dans les paquets, plein de mises à jour, de suppressions, d'installations, en fonction des dépendances mises à jour. Ensuite, on garde longtemps sa distribution. Les distributions fonctionnant avec un système de version encouragent les utilisateurs à les réinstaller tous les 6 mois ou tous les ans. Une distribution rolling release s'installe une fois et se garde des années.

Cependant, pour que cette distribution continue de fonctionner correctement même après des années, il faut qu'elle soit propre. Le premier pas en ce sens est la suppression automatique des paquets qui ne sont plus nécessaires.

Setup garde, pour chaque paquet, un compteur d'utilisation. Par exemple, si A et B dépendent de C et sont tout deux installés, C aura son compteur à 2. Si A et B sont supprimés, C attrape un score de zéro. Ensuite, si C est wanted, on ne fait rien. Sinon, on indique à l'utilisateur qu'il n'est plus nécessaire. «Setup autoremove» se chargera de présenter une liste comme celle de la mise à jour, où l'utilisateur peut choisir quels paquets garder, et quels paquets supprimer.

Nouvelles fonctionnalités à venir

Avant la sortie de Setup alpha2, puis de la beta1, il faut encore deux fonctionnalités, qui seront très utiles.

Paquets Delta

Comme précisé dans mon journal Quelques jours/semaines de silence, je travaille actuellement à l'élaboration d'un algorithme de différences binaires parfait, c'est à dire calculant les plus petites différences. Pour cela, les algorithmes les plus recherchés sont utilisés, comme ceux entrant en jeu dans la bio-informatique, l'optimisation de compilateurs, les calculs de probabilités, le raisonnement spatial, etc.

Une branche Git locale contient les quelques centaines de lignes implémentant un diff basique, qui fonctionne, mais souffre d'un gros défaut : la mémoire. Prenons un exemple, la différence entre l'exécutable initng en version Git de septembre et la version Git de janvier. Cet exécutable fait 87 Kio. BSDiff me sort un patch de 8 Kio. Pas mal, mais comme je l'avais une fois dit, bsdiff compresse ce patch en BZip2, ce qui m'empêche de le recompresser en XZ après. 6 patches de 10 Kio feront un paquet delta de 60 Kio, peu importe la manière dont je le comprime. Il est rejeté pour cela.

Vient ensuite Setup Diff. En mode «consommation faible de mémoire», il me sort un patch de près de 200Kio, 40 Kio compressé en XZ. C'est déjà pas mal, surtout que 6 patches de 100 Kio feront un paquet delta de 600 Kio, pouvant par exemple être ramené à 40 ou 50 Kio par compression . Maintenant, en mode «bonne compression», il me sort l'incroyable patche de 40 Kio, mais après avoir consommé 1,5 Gio de RAM ! Bon, ok, ça compresse bien, mais hors de question de faire swapper un serveur pour un bête fichier de 80 Kio, non non non (qu'est-ce qui arriverait si je devais réempaqueter une version différente d'une image de 2Mio, devrais-je consommer 1000 To de RAM ?)

Il faut donc que je trouve un moyen de réduire ceci, mais là où la RAM ne gène pas, Setup surpasse largement bsdiff. Les différences entre un fichier XML de 8Kio prennent 45 octets avec Setup, compressé en LZMA. Bsdiff me demande quant à lui 194 octets .

Une fois cet algo fait, on pourra profiter de jolis paquets delta permettant une mise à jour rapide et sûre.

CD de paquets

Un nouveau type de dépôts, prévu depuis longtemps, doit aussi faire son arrivée. Il faudra permettre aux utilisateurs d'installer des paquets depuis un CD, pour ainsi lui permettre de télécharger des Add-On CD, puis d'installer des paquets sur des machines non-reliées à Internet.

Néanmoins, ceci nécessite quelques modifications dans Setup :

• Les communications venant du système et pas du paquet («Veuillez insérer le CD "Mon CD tout joli"»)
• L'enregistrement dans la base de donnée de ces paquets, donc enregistrer ces dépôts dans le sources.list, et demander les CDs à chaque setup update, ou alors une seule fois et garder ça en cache.
• «Téléchargement» depuis le CD, donc monter le CD, vérifier que c'est le bon, demander d'insérer le bon CD, etc.

La difficulté est de monter ce CD. Hors de question malheureusement d'utiliser Solid ou tout autre machin lié à KDE. Il faut utiliser du Qt pur, et d'autres libs. Si quelqu'un me trouve comment savoir si un CD est inséré, le monter ou l'éjecter grâce à l'API DBus de udev, alors je n'aurai plus trop de mal. En effet, Qt fournit QtDBus, donc c'est facile . Utiliser mount ne suffit pas, car il faut savoir si le CD a été monté par l'autorun de KDE, informer éventuellement KDE que le CD est monté (udev le fait), etc.

La création des paquets

Et voici la bonne nouvelle : j'ai décidé de tout doucement commencer à créer les paquets, dans les prochains jours. Au début, ça ira doucement, car il me faudra modifier quelque peu Setup (lui ajouter des scripts automatiques, changer de petits machins, etc). Ainsi, j'espère que pour la semaine prochaine (vacances ce carnaval, mais si c'est comme l'année dernière, les français seront en vacances avant et après mois, aucun pendant ) on aura une infrastructure permettant de facilement créer des paquets, et les uploader sur le serveur. Vérifiez donc le petit cadre «Derniers paquets» de la page d'accueil, qui pourrait bientôt contenir des trucs du genre «bash», «sed», «gcc», et autres machins pas trop passionnants.

Viendra ensuite la compilation du noyau (utilisant BFS ), la création d'un initrd, la compilation de Qt, de KDE, etc. Il faudra ensuite que je me familiarise avec Casper et autres, pour créer un LiveCD testable, mais non-installable. Il faudra ensuite que je publie une image disque compressée à recopier fichiers pas fichiers, pour qu'on puisse développer pour Logram par Logram, y compris un installateur.

D'ailleurs, il sera temps de penser à une infrastructure d'installation graphique des paquets, normalement pas basée sur Shaman (il est trop lent et trop abstrait, il refait ce que liblpackages fait déjà). Il faudra faire ça bien, par exemple un simple shell graphique utilisant QtScript pour construire son interface. Ainsi, il sera simple de créer l'interface de gestion des paquets simple, avancée, niveau add-ons, d'installation, etc. N'importe qui pourra personnaliser son interface très facilement .

Patience, patience .