Les modèles, c'est simple

On a beaucoup entendu parler modèles, ces derniers temps chez Calculate : ceux-ci sont introduits un peu partout, on les dit être une fonctionnalité phare de la distribution … bref ! Si comme moi vous restez toujours perplexe, je vous invite à lire l’explicatif qui suit, proposé par le chef du projet CL Alex Tratsevskiy ; il apportera peut-être de la lumière.

Je le mets en tutoriels parce qu’il semble expliquer quelques principes de base, mais vous n’y trouverez pas de recette toute faite. Un homme averti en vaut deux :slight_smile:

La banalisation progressive des modèles serait due à trois facteurs :

  • Le matériel évolue rapidement, mais les outils standards n’arrivent pas à suivre cette évolution, il faut donc y suppléer ;
  • Les modèles utilisent tous le même format qu’il suffit de comprendre une fois pour pouvoir s’en servir par la suite ;
  • Les modèles peuvent se charger de nombreuses tâches, ce qui en fait un dispositif quasiment universel.

Comment gèrent-ils les dépendances ?

Comme il a été dit et redit par l’équipe, CL n’utilise plus les méta-paquets par souci de simplicité. Il a fallu par contre voir pour la gestion du fichier world (/var/lib/portage/world, pour vous rappeler le chemin complet). A priori, on ne voudrait pas qu’elle soit générée par des modèles : même si obéissant à une même consigne de format, ces derniers peuvent être très différents. Mais comme ils ont assez d’autonomie pour pouvoir créer leurs propres scripts de configuration, cela ne devrait pas poser problème. Les utiliser pour la gestion des dépendances présente par contre plusieurs avantages :

  • Les méta-paquets apportaient vraiment des soucis. Avant CL 13, si vous vouliez supprimer un paquet faisant partie de la distribution, vous deviez, pour qu’il ne soit pas réinstallé lors de la prochaine mise à jour, désactiver, avec un USE spécial, le méta-paquet auquel il appartenait, le supprimer, puis porter les autres paquets qui en restait sur la liste world pour éviter leur suppression, tous ça à la main… pénible.
  • Les sets auraient pu faire l’affaire, avec leur sélection thématique et leur facilité de description, mais sans paramètres USE ils ne seraient pas suffisamment configurables. Cela reviendrait un peu au même que l’histoire des méta-paquets.
  • L’idée de confier la génération du fichier world aux modèles n’est pas nouvelle : cette procédure avait été mise en oeuvre pour les anciennes versions de Calculate Linux, avec un résultat satisfaisant.
  • Les modèles ont beaucoup évolué depuis, en devenant plus adaptés à cette tâche. Un nouvel événement a été introduit pour appliquer les modèles lors de la mise à jour de Portage, avec eix-sync.

Pour résumer, sur CL 13 le fichier world est créé au moment de l’assemblage du système et fait référence à une version du ‘pack’ d’applications utilisées. Le numéro de version est contenu dans le fichier /etc/calculate/ini.env:

[update]
world = 3

Les modèles éditent le liste world via l’événement de mise à jour (pour l’heure, l’utilité de Calcutate Update s’arrête là). Ceci est valable pour toute modification faite par l’utilisateur au niveau des applications : si vous supprimez, disons, Audacious, le système ne vous proposera pas d’autre lecteur audio pour le remplacer.

Au passage à la version 3, par exemple, les paquets net-wireless/madwifi-ng et net-wireless/madwifi-ng-tools seront supprimés du fichier world. Ils ont été masqués par les mainteneurs de Gentoo comme inutiles : les pilotes qu’ils fournissaient sont désormais activables par recompilation du noyau. Si les paquets masqués restaient sur la liste world, des blocages très embêtants en résulteraient lors de la mise à jour.

Si vous désirez reconstituer la liste world initiale, vous n’avez qu’à exécuter 'cl-update --rebuild-world'.

Actuellement on trouve les modèles world dans :

/var/lib/layman/calculate/profiles/templates/3.1/6_ac_update_sync/world

Que font les modèles de configuration ?

La barre du bas de toute version bureau de Calculate Linux contient les raccourcis des applications principales. Les icônes que vous y voyez sont définies par les fichiers desktop, localisés dans le répertoire /usr/share/applications. Malheureusement, on ne sait jamais ce qui pourrait arriver à ce petit monde : ils sont souvent renommés soit par les développeurs, soit par les mainteneurs de Gentoo, voire remplacés par l’utilisateur qui préfèrerait une autre application plutôt que celle proposée par l’équipe CL. Grâce aux nouveaux modèles, les raccourcis de la barre vont toujours correspondre à votre liste d’applications principales, même si vous l’avez personnalisée. Les fichiers desktop qui réfèrent à la barre du bas ont des noms qui commencent avec ‘calculate’ et contiennent le type d’application concerné (comme dans calculate-browser.desktop).

Les modèles de configuration ont été complètement réécris pour CL 13, afin de pouvoir

  • reconfigurer une application par défaut dans le cas où l’application courante serait supprimée,
  • configurer une application par défaut comme application préférée pour ouvrir un type de fichiers spécifique.

La liste des applications par défaut se trouve dans /etc/calculate/ini.env dont voici un extrait exemple :

[desktop]
browser = chromium
mail = claws-mail
chat = xchat
...

Pour tester, intallez Firefox, puis supprimez Chromium qui est fourni pas défaut dans toutes les versions CL. Si vous utilisez CLDX, un relogin s’impose une fois le remplacement fait. Vous verrez l’icône Firefox sur la barre du bas, et si vous consulter le fichier /usr/share/applications/mimeapps.list, vous remarquerez qu’il a été réécrit également. Ceci grâce aux modèles que l’on trouve dans :

/var/lib/layman/calculate/profiles/templates/3.1/2_ac_install_merge/Desktop

Tenez, un exemple de plus, réel cette fois-ci et non pas imaginé. A peine CLDX 13 sortie, une nouvelle version du terminal, Terminal 0.6.0, a été proposée dans Portage. Mais c’était xfce4-terminal.desktop qui décrivait le launcher et non plus Terminal.desktop ; d’ailleurs le paquet lui-même a été renommé de x11-terms/terminal en x11-terms/xfce4-terminal (v. /usr/portage/profiles/updates/4Q-2012). Même le chemin vers les fichiers de configuration avait changé ! Le saviez-vous ? Si vous l’ignoriez, c’est que les modèles se sont bien acquittés de leur tâche.

C’est quoi les révisions système ?

Calculate Linux 13 introduit la notion de révision système. Pour connaître le numéro de révision, référez-vous au paramètre 'rev' de votre /etc/calculate/ini.env:

[update]
rev = 1

Les révisions seront utilisées à effectuer des mises à jour ponctuelles au rythme régulier, pour éviter que votre système parte en vrac après une mise à jour apocalyptique. Elles ont remplacé les modèles utilisés à gérer les mises à jour des méta-paquets. Leur numérotation n’a rien à voir avec les sorties de la distribution ou de paquets. Ainsi, la première révision a-t-elle été validée juste avant la CL 13 finale, visant à corriger la liaison de /usr/share/applications/mimeapps.list à x11-base/xorg-server.

Ce fichier lie les applications par défaut à leurs fichiers MIME respectifs. Avant la CL 13, il était généré par un modèle appliqué lors de l’installation de x11-base/xorg-server qui associait justement le fichier au paquet. A la réinstallation de ce paquet, tous les réglages seraient donc effacés ; la révision 1 a supprimé la liaison fautive.

Pour l’instant, les révisions sont localisées à

/var/lib/layman/calculate/profiles/templates/3.1/6_ac_update_sync/revision

Conclusions

Vous aurez déjà remarqué que certains réglages système sont sauvegardés dans votre /etc/calculate/ini.env. Ce fichier, à la différence du calculate.env que l’on trouve dans le même répertoire, ne contient pas de valeurs de variables, mais des paramètres de modèles. Les modèles les lisent et écrivent dedans sans qu’on ait à s’en soucier : on peut donc se concentrer sur la logique de leur agencement, sur la configuration proprement dite.

C’est Portage, avec son approche rolling-release, qui permet à ce dispositif de fonctionner, pour qu’un utilisateur avancé puisse personnaliser le système certes, mais aussi pour que les développeurs puissent ajouter le support de tel ou tel logiciel à tout moment, sans attendre la prochaine sortie pour l’implémenter.