El 18/10/04, a les 19:01:53, C. Gatzemeier ens deleit� amb les seg�ents paraules: [...] > Multilevel config files would sure be nice, where the apps don't support them > it might be sufficient to provide only multilevel *defaults*. Multilevel as > application defaults, package defaults, system defaults (CDDs) and possibly > admin defaults. That should be possible with any type of app configuration. > Eeach level of authority could optionally provide a description of their > defaults that are processed by a configuration helper as CFG that is designed > to never interfere with user settings as described at > http://freedesktop.org/Software/CFG [...]
Ok, first of all, sorry if my ideas are not correct, as i'm not sure how exactly CFG or all the other config system tools work, but as i see it, the problem resides on two main points, i think: - Programs must be modified to use the config system - Users can't directly access config files without breaking config system's coherence So looking at this two points, i see the need of a top level transparent interface... And here's my half of a cent: What if we build a new file system (in the idea of transparent external access from hurd translators: http://www.debian.org/ports/hurd/hurd-doc-translator) starting on /etc that "catches" all file operations and acts as a frontend to many possible config system backends? That is, if the package installs a new config file, we (the file system) catch that operation and instead take that new file and "translate" it to, for example, CFG (or a database system, or whatever)'s input. In that way, we catch any addition or manual edition, so there's no need on the program to change it's behaviour (and as reading can also be supervised by the fs, we give the program the data that the backend config system is storing). How to differentiate the package diversions from manual editions? As a concrete process is initiating the modifying operation, we can traverse the process hierarchy until we get a dpkg process (so we know it's a new file installation, and the package it belongs to), a dh_ script (on a possible debhelper modification operation, if any available - I don't know if there's such a thing) or init, bash, editor, or wathever we choose (so it's a manual edition then, with the possibility of knowing some data as the date, user, etc). I presented CFG as one of the possible backend options as it stores a hierarchized bunch of data, and we can deduce that hierarchy from the current system status (diversions, system/package "tunnings", manual editions), but I don't really know if, for example, it can work without the meta-config definition that the web page talks about. Well, I don't know if that's like killing flyies with cannons (sorry for my literal traduction ;)), or product from my own sick half-slept mind... it probably is the last option XD Sleep well! -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
