File life after a template

Updated 6 Novembre 2026

Contenu texte

Un modèle ne fait pas qu'écrire un fichier : il l'associe à son paquet, marque sa source et assume la responsabilité des fusions ultérieures. D'où quelques règles qui vous épargneront bien des tracas.

L'en-tête de service

Au début du fichier créé par un modèle, les utilitaires écrivent un bloc de ce type :

#------------------------------------------------------------------------------
# Modified Calculate Utilities 3.7.6.8
# Processed template files:
# /var/calculate/templates/merge/editor.sh
# To modify this file, create a /etc/profile.d/editor.sh.clt template.
#------------------------------------------------------------------------------

Il remplit trois fonctions. Il indique quels modèles ont participé à la création du fichier (lorsque plusieurs sont fusionnés, c'est le seul moyen de connaître leur origine). Il suggère la bonne manière de modifier quelque chose - créer un modèle .clt, et non éditer le fichier à la main. Et c'est grâce à lui que les utilitaires, lors de la fusion suivante, reconnaissent leur partie et la retirent, pour ne pas accumuler de copies : le caractère de comment= doit donc être un commentaire pour le programme cible, sinon le fichier devient illisible.

Le fichier appartient à un paquet

Un fichier créé par un modèle associé à un paquet (mergepkg(), pkg(), <category>/<package>/…) est enregistré dans la liste des fichiers du paquet. Vous pouvez le vérifier avec les outils Portage habituels :

equery f sys-apps/baselayout | grep profile.d
/etc/profile.d
/etc/profile.d/editor.sh
equery b /etc/profile.d/editor.sh
sys-apps/baselayout-2.18-r1
equery b /etc/sysctl.conf
sys-apps/openrc-0.63.3
qcheck sys-apps/baselayout
Checking sys-apps/baselayout ...
 MTIME: /etc/mtab
  * 41 out of 42 files are good

La dernière ligne donne le ratio global : quels fichiers se retrouvent dans la liste des divergences et quel sera ce nombre, dépend des modèles fusionnés sur le système et de ce qui a été modifié à la main. Orientez-vous sur la liste des chemins, pas sur le nombre : c'est elle qui indique où regarder.

Notez la sortie de equery b /etc/sysctl.conf : l'appartenance du fichier détermine à quel paquet votre modèle doit être associé - pour

Notez la sortie de equery b /etc/sysctl.conf : l'appartenance du fichier détermine à quel paquet votre modèle doit être associé - pour /etc/sysctl.conf et les fichiers de /etc/sysctl.d c'est sys-apps/openrc, et non sys-apps/baselayout. La ligne MTIME: /etc/mtab n'est pas comptée comme divergence : ce fichier change au démarrage du système.

ce fichier change au démarrage du système.

Bonne nouvelle : vous n'avez pas besoin de "duper" le gestionnaire de paquets - un modèle correct rend le fichier légal de lui-même. Si qcheck signale une divergence alors que le fichier a été créé par vous, il est apparu hors du contrôle du paquet (par exemple, un modèle "brut" sans mergepkg() lors de la configuration du système entier) - corrigez l'association, ne réparez pas les sommes de contrôle.

Protection du fichier et mise à jour des paramètres

  • protected - le fichier n'est pas supprimé lors de la suppression du paquet auquel il appartient. À utiliser pour les paramètres dont la valeur survit au paquet (par exemple, clés, caches, fichiers créés lors de l'installation).
  • autoupdate - à l'installation du paquet, un fichier de configuration modifié est transféré dans le système immédiatement ; sans lui, la modification reste en "attente" et est appliquée via dispatch-conf (cl-dispatch-conf), où vous décidez vous-même quoi accepter. Si le système contient déjà un fichier du paquet que vous avez modifié, il ne sera pas remplacé en silence - c'est précisément le rôle de dispatch-conf.
  • force - supprimer le fichier existant avant l'écriture ; activé automatiquement avec symbolic.
  • mirror - fusionner uniquement si le fichier de configuration existe déjà ; si la cible est définie via link= et qu'elle n'existe pas, le fichier est supprimé. Pratique pour les modèles qui doivent "suivre" le fichier réel, mais pas le créer de toutes pièces.
  • chmod=, chown= - les droits et le propriétaire du résultat ; s'ils ne sont pas indiqués, les droits du modèle sont utilisés (ou ceux de l'original, s'il y en avait un).

Quand supprimer ou "nettoyer"

  • append=remove - supprime le fichier (pour un répertoire - le répertoire avec son contenu). C'est le moyen prévu pour retirer ce qui n'est plus nécessaire : un modèle supprimé ne supprime rien lui-même dans le système.
  • append=clear - met le fichier à zéro (longueur 0) ; pour un répertoire - supprime tout son contenu en conservant le répertoire lui-même.

Il n'existe pas de valeur append=delete ; toute suppression se décrit par ces deux moyens avec remove/clear.

Retirer son modèle dans les règles

Supprimer simplement le fichier de /var/calculate/templates ne suffit pas ne suffit pas

Supprimer simplement le fichier de /var/calculate/templates ne suffit pas ne suffit pas

ne suffit pas ne suffit pas

ne suffit pas ne suffit pas : le fichier de configuration qu'il a créé restera dans le système et continuera d'être rattaché au paquet. L'ordre est le suivant :

  1. remplacez le modèle par un modèle "supprimant" - append=remove avec les mêmes path=/name=, et appliquez la configuration du paquet ;
  2. supprimez le modèle lui-même ;
  3. si le fichier appartenait à un paquet, vérifiez son état : equery f <package>, et réinstallez le paquet si nécessaire (emerge -1a <package>).

Voir aussi