Who and when merges templates

Updated 5 Novembre 2026

Contenu texte

Le modèle n'est pas appliqué "quand bon semble" mais au moment d'une action précise. Ce sont les variables d'action ac_* qui déterminent quels modèles fusionner cette foisN_ac_<événement>.

L'ensemble réel des répertoires dans l'arbre calculate :

1_ac_install_disk         6_ac_desktop_profile
2_ac_install_merge        6_ac_install_config
3_ac_install_live         6_ac_install_configure
5_ac_ad_client            6_ac_install_flash
5_ac_client_configure     6_ac_install_patch
6_ac_backup_create        6_ac_install_pxe
6_ac_backup_restore       6_ac_install_unmerge
6_ac_backup_service       6_ac_update_sync
6_ac_builder_container    7_ac_server_ldif
6_ac_builder_iso          7_ac_server_setup
6_ac_builder_prepare      9_ac_install_merge
6_ac_builder_setup        deprecated
6_ac_builder_squash

L'ensemble dépend de la révision du dépôt : deprecated et une partie des 6_ac_builder_* peuvent y manquer. Vous obtenez la liste complète et à jour avec ls /var/db/repos/calculate/profiles/templates/.

Le préfixe numérique dans le nom du répertoire d'événement fixe l'ordre par rapport aux autres répertoires ; l'ordre des fichiers dans un même répertoire est décrit sur la page des répertoires de modèles. L'action elle-même est choisie par l'en-tête dans .calculate_directory, et non par le nom du répertoire.

Événements principaux

Configuration d'un paquet

Les événements 2_ac_install_merge, 9_ac_install_merge et 6_ac_install_unmerge - ils ont lieu lors de l'installation, de la mise à jour et de la suppression d'un paquet : emerge. C'est implémenté par des hooks Portage - des fragments de profile.bashrc situés dans /var/lib/calculate/profile.bashrc.d/ et générés eux-mêmes par des modèles. C'est ici que fonctionnent les modèles de la forme [HTML_REMOVED]/[HTML_REMOVED]/…, et la condition mergepkg([HTML_REMOVED]/[HTML_REMOVED])!= проверяет, что настраивается этот пакет.

Un détail important qui explique la moitié des questions "pourquoi rien n'a été appliqué" : les modèles du paquet ne sont fusionnés que si le paquet figure dans les caches /var/lib/calculate/calculate-core/cache/merge-setup.list (configuration) ou merge-patch.list (correctifs). Ces listes sont mises à jour par /usr/libexec/calculate/cl-pkg-cache lors des phases d'installation/suppression. Pas de paquet dans le cache - pas d'application non plus, même si le modèle est écrit correctement.

Modification des sources du paquet

L'événement 6_ac_install_patch se lance avant la compilation, et les modèles de cet événement appliquent des correctifs (généralement format=diff). En cas d'erreur de fusion, la compilation peut être interrompue.

Mise à jour du système et synchronisation de l'arbre Portage

L'événement 6_ac_update_sync est appelé par l'action update. cl-update le lance, et lors de la synchronisation de l'arbre Portage c'est le module de synchronisation Calculate dans portagedes répertoires portant des noms-datés (2026/20261103), appliqués une seule fois, et un modèle type vérifie la révision de l'overlay via ini(overlay-calculate.remerge)<#-cl_pass_file-#>. La condition ac_update_sync==on est remplie lors des actions de synchronisation et de changement de profil, quand le paquet à configurer n'est pas indiqué. La variable appartient au module update et est en lecture seule : vous ne pouvez pas la définir manuellement, l'action elle-même la définit, c'est pourquoi vous l'écrivez dans l'en-tête avec le module - env=update ac_update_sync==on, le répertoire livré 6_ac_update_sync est organisé exactement ainsi, avec # Calculate append=skip env=update ac_update_sync==on.

Installation et démarrage du système

Les événements 1_ac_install_disk, 3_ac_install_live, 6_ac_install_flash et 6_ac_install_pxe - la configuration du système en cours d'installation (cl-install), de l'image live, du démarrage depuis USB-Flash et par le réseau.

Profil utilisateur

L'événement 6_ac_desktop_profile a lieu lors de la connexion de l'utilisateur à une session (via cl-desktop), et aussi lors de l'installation d'un paquet sur un système de travail - alors le profil déjà créé reçoit une configuration complémentaire. Les variables ur_* et le chemin ~ participent à cet événement, et la couche clt n'est pas utilisé.

Configurateur spécifique

Les événements 6_ac_install_configure, 5_ac_client_configure et 7_ac_server_setup - des actions par type de configuration : réseau, son, chargeur de démarrage, locale, session, thèmes, vidéo (cl-setup-network, cl-setup-locale, … - voir cl-core --list-methods). La condition dans le modèle vérifie généralement cl_setup==[HTML_REMOVED] avec ac_install_configure==on.

Domaine

5_ac_ad_client couvre l'entrée de la machine dans le domaine et la sortie du domaine.

Création d'une image

6_ac_builder_* couvre les actions du constructeur (iso, squash, container, prepare, setup).

Une même exécution peut activer plusieurs événements

C'est une source fréquente de surprises. Les variables ac_install_merge et et ac_install_live sont activées en même temps si vous lancez la configuration d'un paquet directement sur un système déjà installé ( sont activées en même temps si vous lancez la configuration d'un paquet directement sur un système déjà installé (cl-core-setup …, , cl-setup-system)) :

C'est une source fréquente de surprises. Les variables ac_install_merge et et ac_install_live sont activées en même temps si vous lancez la configuration d'un paquet directement sur un système déjà installé ( sont activées en même temps si vous lancez la configuration d'un paquet directement sur un système déjà installé (cl-core-setup …, , cl-setup-system)) : ac_install_live n'est pas réservée au "LiveCD uniquement". Dans le chroot de Portage (lors de la construction d'un paquet) le mode live est désactivé, et merge reste. D'où la règle pratique : si le modèle concerne précisément l'image live, vous devez le placer dans 3_ac_install_live et vous appuyer sur les différences d'environnement, plutôt que de compter sur l'événement "installateur". et vous appuyer sur les différences d'environnement, plutôt que de compter sur l'événement "installateur".

si le modèle concerne précisément l'image live, vous devez le placer dans 3_ac_install_live et vous appuyer sur les différences d'environnement, plutôt que de compter sur l'événement "installateur". et vous appuyer sur les différences d'environnement, plutôt que de compter sur l'événement "installateur".

ac_install_disk est définie quand l'action est une installation du système (et non flash/pxe).

Lancement manuel

La façon la plus courante de vérifier votre modèle :

cl-core-setup -n [HTML_REMOVED]

  • -v - sortie détaillée avec la liste des modèles appliqués et des erreurs ; pour core_setup elle est activée par défaut, donc vous pouvez omettre le drapeau dans les exemples ;
  • -c [HTML_REMOVED] - la catégorie du paquet ; vous n'êtes pas obligé de l'indiquer. Les homonymes entre catégories différentes sont rares, et cl-core-setup -n baselayout suffit. -c servira à distinguer ces cas ; et connaissez l'autre face : avec une catégorie erronée, pas un seul modèle n'est appliqué, et sans message d'erreur - la vérification affichera simplement un résultat vide ;
  • --pkg-path [HTML_REMOVED] - diriger les résultats vers un répertoire sans modifier les fichiers de configuration eux-mêmes (voir aperçu) ; le répertoire doit exister, sinon vous obtenez Error in parameter --pkg-path. Attentionune telle exécution ajoute dans CONTENTS plusieurs lignes qui n'étaient pas dans la sortie de equery f <package>. Avant l'essai, enregistrez cette sortie, et après - comparez-la avec le CONTENTS actuel et retirez les lignes apparues ;
  • -T - choisir les couches de modèles dans un ensemble fixe : calculate, distros, local, remote, clt ; none désactive complètement la sélection.

La liste des actions disponibles : cl-core --list-methods.

Voir aussi