Directories as templates and storage layers

Updated 5 Novembre 2026

Les modèles forment un arbre, et l'arbre lui-même fait partie de la description : un répertoire peut être un modèle et porter les conditions communes à tout ce qu'il contient.

Répertoire comme modèle

Les propriétés du répertoire sont décrites dans le fichier .calculate_directory à l'intérieur de celui-ci. C'est un en-tête de modèle ordinaire

# Calculate append=skip env=install ac_install_merge==on

L'en-tête du répertoire est hérité par tous les modèles à l'intérieuril ne fonctionne que lorsque le répertoire participe lui-même à la fusion (sans append=skip). Un répertoire avec append=skip sort de la chaîne - avec son path=, si bien qu'un fichier sans son propre path= ira où le nom de la chaîne restante de répertoires le dirige.

Les répertoires disposent des mêmes paramètres que les fichiers, mais l'ensemble est plus restreint : append=, path=, name=, link=, chmod=, chown=, mirror, subvolume, autoupdate, env=, module=, merge=, postmerge=, rebuild=, restart=, start=, stop=. format=, comment=, symbolic, protected, force, run=, exec= ne s'appliquent pas à un répertoire.

Un répertoire autorise append=join|remove|skip|clear, et append=replace seulement avec link= (voir ci-dessous) :

• append=skip - le répertoire n'est pas transféré dans le système (c'est généralement ce qu'il faut) ; avec lui, son path= n'entre pas non plus dans le chemin des résultats ;
• append=clear - vider le contenu du répertoire de configuration ;
• append=remove - supprimer le répertoire ;
• append=join avec link= - transférer dans le répertoire créé le contenu d'un autre.

link= sur un répertoire ne se combine qu'avec append=join ou append=replace (avec replace, les fichiers de la cible sont supprimés avant la copie).

Nommage des répertoires : <category>/<package>

Dans les répertoires de configuration de paquet (N_ac_install_merge, N_ac_install_unmerge, N_ac_install_patch, …), la structure doit correspondre au paquet :

2_ac_install_merge/
└── sys-libs/
    └── ncurses-6.1/
        ├── .calculate_directory
        └── ncurses.sh

Le nom du répertoire du paquet définit le paquet auquel le modèle est associé : les fonctions merge(), mergepkg(), pkg() sans arguments prennent la catégorie et le nom du paquet depuis le chemin, en éliminant les préfixes de tri et les versions (05-, -4.6). La présence d'une version dans le nom est un moyen de lier le modèle à une plage de versions.

Couches de stockage et priorité

Les modèles se trouvent dans plusieurs "couches" ; les noms des couches correspondent aux dépôts connectés. Sur un système réel, cela ressemble à ceci :

calculate:/var/db/repos/calculate/profiles/templates,distros:/var/db/repos/distros/profiles/templates,local:/var/calculate/templates,remote:/var/calculate/remote/templates

• Les couches des dépôts (calculate, distros, …) sont les répertoires profiles/templates des dépôts connectés. La distribution les crée et les met à jour : elles ne doivent pas être éditées, et à la prochaine synchronisation les changements disparaîtront.
• local - /var/calculate/templates, la couche utilisateur. C'est là que vous placez vos propres modèles.
• remote - /var/calculate/remote/templates : les modèles reçus d'un serveur Calculate (utilisés dans la configuration de domaine).
• clt - les modèles de substitution situés à côté du fichier configuré dans /etc, avec l'extension .clt.

Un modèle qui se retrouve dans deux couches avec la même adresse (path + + name + + link) gagne par la priorité de la couche : la couche utilisateur prime sur le dépôt, donc vous pouvez remplacer un modèle système sans toucher au fichier lui-même.

Lors de la configuration, vous choisissez quelles couches participent avec le paramètre -T/--templates :

Les valeurs possibles sont fixes

Les valeurs possibles sont fixes : calculate, distros, local, remote, clt et none. Ce ne sont pas les noms de n'importe quel dépôt connecté : le dépôt gentoo est connecté lui aussi, mais en tant que couche de modèles il n'existe pas, et l'utilitaire rejette est connecté lui aussi, mais en tant que couche de modèles il n'existe pas, et l'utilitaire rejette -T gentoo. Pour la configuration du profil utilisateur, la couche . Pour la configuration du profil utilisateur, la couche clt ne participe pas. ne participe pas.

Ordre dans l'arbre

Les répertoires de premier niveau définissent l'action par leur en-tête, et non par leur nomles répertoires sont parcourus en ordre lexicographique, donc le chiffre au début du nom définit la séquence de fusion et ne participe pas au choix de l'action. Dans un événement, le même ordre vaut aussi pour les fichiers : les préfixes numériques (05-rebuild_openrc) sont un moyen de définir l'ordre, pas une partie du nom du paquet. Quelles sont les actions et qui les active - voir Qui fusionne les modèles et quand.

Si un fichier a besoin de plusieurs modifications provenant d'endroits différents, vous pouvez les répartir sur des fichiers triés par nom : ils seront appliqués dans l'ordre alphabétique au sein d'un même répertoire.

L'outil qui écrit les modèles lui-même : cl-kernel

Presque tous les utilitaires ne font que fusionner les modèles. cl-kernel (le paquet sys-apps/calculate-toolkit, un script bash installé dans /usr/sbin/cl-kernel) fait les deux : il construit le noyau et transforme vos modifications de configuration en un modèle ordinaire dans le stockage utilisateur - /var/calculate/templates/kernel/.

Comment cela fonctionne :

• au premier lancement, /var/calculate/templates/kernel/.calculate_directory est créé avec l'en-tête # Calculate env=install ac_install_patch==on append=skip - la variable d'action du répertoire de premier niveau plus append=skip, pour que le répertoire lui-même n'apparaisse pas dans le système ;
• le nom du modèle est construit à partir de la série du noyau : 10-config-<architecture>-<MAJOR.MINOR> (pour les paquets de la forme *-sources - 10-<name>-<architecture>-<MAJOR.MINOR>), donc l'association porte sur une version précise et ne gêne pas les autres ;
• l'en-tête du modèle porte le format et l'association : # Calculate format=kernel name=.config os_install_arch_machine==<architecture>&&merge(<category>/<package>)>=<version> ;
• le contenu du modèle n'est que la différence entre la configuration de base (make defconfig, déjà avec les modèles fusionnés) et ce que vous avez obtenules options absentes du modèle restent dans le fichier telles quelles ;
• le modèle précédent de la même série n'est pas supprimé mais déménage dans /var/calculate/templates/kernel/backup avec l'en-tête # Calculate cl_action==skip - il reste sous la main sans être fusionné.

L'intérêt est que la configuration du noyau cesse de faire partie d'un seul système construit. Le modèle survit à la réinstallation du paquet, à la mise à jour de la série et à la reconstructionil appelle cl-core --method core_patch avec --pkg-name, --pkg-category, --pkg-version et --pkg-path pointant vers un répertoire doublon où se trouve le .config de base - sans construire le noyau. Si vous lancez cette passe manuellement pour un autre paquet, vérifiez qu'il existe bien des modèles d'action ac_install_patch pour ce paquet : sinon le répertoire doublon restera vide, et ce n'est pas une erreur mais l'absence de modèles adaptés. La méthode générale pour voir le résultat à l'avance est dans l'aperçu du modèle.

Pour reporter l'association sur d'autres machines, le répertoire kernel est placé dans un overlay (profiles/templates/kernel/) et diffusé comme un paquet : ainsi, des noyaux identiques sur des machines différentes sont construits à partir du même jeu de modèles. Pour la référence de l'utilitaire lui-même, lisez la page sur le noyau, et les sources dans calculate-toolkit.

Voir aussi

• Syntaxe du modèle - les paramètres de l'en-tête.
• La vie d'un fichier après son modèle - à qui appartient le fichier créé.
• Le modèle ne s'est pas appliqué et n'a rien dit - où voir quelle couche participe.