Sous Gentoo, l'outil de gestion des modifications induites par les packages dans / etc (appelé dispatch-conf) prend en charge rcs pour suivre les modifications, mais ce n'est pas vraiment puissant.
J'ai tendance à versionner mon / etc via git
, d'autant plus qu'en utilisant différentes branches, je peux garder mon / etc aussi similaire que possible sur différentes distributions tout en conservant autant de choses en un seul endroit que possible (pour certaines zones qui échouent évidemment, configuration apache par exemple, est vraiment différent selon les différentes distributions). Cela fonctionne comme ceci:
J'ai mon master
dépôt avec mes fichiers de configuration par défaut. Maintenant, j'entre en contact avec une nouvelle distribution donc je crée une nouvelle branche basée sur ma master
branche basée sur le nom de la distribution (dans cet exemple debian). Debian conserve un fichier de configuration dans un emplacement différent du mien, master
donc je fais un git mv file new_loc
. Et tout va bien. Je reviens master
et change ce fichier parce que j'ai ajouté une directive de configuration spécifique, quand je fusionne master
dans ma debian
branche, le fichier déplacé est changé, donc je peux simplement changer la plupart des choses dans ma master
branche et juste avoir à fusionner les changements dans ma "distribution" des branches (généralement elles ont tendance à être plus un mélange de branches de distribution et d’objectifs, un serveur Debian a des différences avec une station de travail Debian bien sûr mais les fonctionnalités fonctionnent toujours).
Donc, fondamentalement, j'ai une "configuration générique" dans master
et (pour le dire en termes de programmation orientée objet) hériter ceux de mes branches (qui peuvent également hériter les uns des autres).
En dehors de cela, git
les mécanismes de commits "cherry-pick" (dans ce cas, les modifications apportées à / etc /) m'ont été très utiles à certains moments où je n'avais besoin que de parties d'une certaine configuration.
Passons maintenant à certaines de vos idées:
- Si j'avais besoin de plus d'intégration du gestionnaire de paquets, j'utiliserais probablement des scripts wrapper pour cela (pour le moment, je n'en ai pas).
- traiter les versions en amont comme une branche fonctionnerait bien
git
, c'est juste une autre branche dans laquelle vous fusionnez parfois (partiellement) enmaster
- La liste des ignorés dans git est le fichier .gitignore dans votre référentiel, donc cela est couvert.