J'imaginais une solution basée sur deux fichiers de conf.
Nous aurions un fichier qui ne serait pas modifié par l'utilisateur et mis à jour à chaque fois que nécessaire et [un autre] qui lui ne contiendrait que les différences apportées par l'utilisateur
Le principe pour l'appli serait de lire les cles du kdmrc.default, puis ensuite le kdmrc "utilisateur" et ecraser les cles du premier par celles qu'il y trouve.
Mon idée est-elle farfelue, est-ce que je réinvente la roue, est-ce que j'ai raté le truc gros comme une maison qui fait déjà tout ça ?
En fait ça existe déjà chez OpenBSD.
Il y a les fichier rc / rc.conf et rc.local / rc.conf.local. Les premiers sont livrés avec la distribs et ne devraient pas être édités, les seconds écrasent les valeurs des premiers.
Pareil il y a les resolv.conf.tail et motd.tail qui sont virtuellement des fins de fichiers pour resolv.conf et motd (qui eux sont écrasés). Le resolv.conf je crois que c'est pour le DHCP et le motd ça doit être parce que bon, faut vraiment utiliser sendbug pour envoyer un bug...
# .tail / .local
Posté par theocrite . En réponse au journal Réflexion sur les fichiers de conf.. Évalué à 2.
En fait ça existe déjà chez OpenBSD.
Il y a les fichier rc / rc.conf et rc.local / rc.conf.local. Les premiers sont livrés avec la distribs et ne devraient pas être édités, les seconds écrasent les valeurs des premiers.
Pareil il y a les resolv.conf.tail et motd.tail qui sont virtuellement des fins de fichiers pour resolv.conf et motd (qui eux sont écrasés). Le resolv.conf je crois que c'est pour le DHCP et le motd ça doit être parce que bon, faut vraiment utiliser sendbug pour envoyer un bug...