| 1 |
debconf doesn't seem to be what I was describing. It appears to be a |
| 2 |
system for package managers and package configuration at install time. |
| 3 |
Thus rather distribution specific. |
| 4 |
Though the biggest problem seems to be a lack of online documentation... |
| 5 |
(ok 2min google wouldn't find them anyway, I read the debconf-devel man |
| 6 |
from their subversion repository) |
| 7 |
|
| 8 |
What I was suggesting was an XML-Schema(or DTD) describing a valid |
| 9 |
XML-Schema for valid XML Configuration files. |
| 10 |
Maybe a library for parsing those configuration files that applications |
| 11 |
can link against. |
| 12 |
Apache uses some semi xml for its configuration. XF86Config just lacks |
| 13 |
the '<' and '>' and it would be xml'ish in its syntax... |
| 14 |
It would be totally distribution independent. |
| 15 |
|
| 16 |
Arguments against this would be: |
| 17 |
1. It would be impossible to implement this in a way that suits all |
| 18 |
applications. |
| 19 |
I think it is |
| 20 |
2. Configuration files would be... |
| 21 |
... hard to read |
| 22 |
not once you're used to it |
| 23 |
... ugly |
| 24 |
not if done right |
| 25 |
... bigger |
| 26 |
so? |
| 27 |
|
| 28 |
3. Core system utilities should not depend on an xml-parser |
| 29 |
what do they depend on now? |
| 30 |
|
| 31 |
-John |
| 32 |
|
| 33 |
|
| 34 |
On Sat, 2004-03-20 at 03:46, Andrew Cowie wrote: |
| 35 |
> On Sat, 2004-03-20 at 07:45, John Nilsson wrote: |
| 36 |
> > 1. Standardize a configuration backend. |
| 37 |
> > Fileformat, parsers, filesystemlocation and that stuff |
| 38 |
> |
| 39 |
> I note that Debian went down this exact road with something called |
| 40 |
> "debconf". Anyone considering doing something formal in this space |
| 41 |
> should install a Debian box somewhere and study what debconf is like. |
| 42 |
> |
| 43 |
> They set out with noble objectives (much the same as what you specified |
| 44 |
> above) but ended up with something quite cryptic, hard to follow, and |
| 45 |
> inconsistent. |
| 46 |
> |
| 47 |
> [Recall how people keep saying "can I see those ebuild messages again"? |
| 48 |
> Same sort of problem] |
| 49 |
> |
| 50 |
> 2. Convince developers to follow the standard. |
| 51 |
> |
| 52 |
> Which is tricky - not so much that there aren't uses for it, but rather |
| 53 |
> the mass proliferation of packages means that only some packages use it. |
| 54 |
> More importantly, Gentoo tends to leave configuring software alone, and |
| 55 |
> lets the deploying sysadmin/user deal with it. Debian and RedHat (and..) |
| 56 |
> try to automate creation of a file that may or may not be suitable to |
| 57 |
> your needs, and then layer (in Debian's case) debconf on top of it. |
| 58 |
> |
| 59 |
> The difference between RedHat and Debian in this case is that on a |
| 60 |
> RedHat system you tend to use their tools to interact with the |
| 61 |
> configuration on an ongoing basis. While annoying to us console jockey |
| 62 |
> types, at least its consistent. Debian, on the other hand, tries to |
| 63 |
> accomodate both - you certainly don't revisit debconf... |
| 64 |
> |
| 65 |
> > 3. Interface with it |
| 66 |
> > HTML, QT, GTK anything goes... |
| 67 |
> |
| 68 |
> They never got that far, which is perhaps the problem |
| 69 |
> |
| 70 |
> As ever, we have a lot to learn from each other. |
| 71 |
> |
| 72 |
> AfC |
| 73 |
> Sydney |
Archives