Re: Right Way to make a configuration package
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
Reply to: