Solving the /etc Situation?

mrfibbi asks: "/etc is a mess, plain and simple. Each program has its own (incompatible) config file format and the naming scheme/hierarchy is left almost solely to the author. Furthermore, package updates are a mess, either choosing to replace the entire config file, reject any updated versions (which leads to inconsistencies), or, as is the case with etc-update, asking the user to manually merge the files, which takes forever after a big update. We've revamped /dev with udev, but we've still failed to come up with a universal, duct-tape-free solution for the problem. Though solutions exist, there has been little or no adoption, either due to a personal dislike for the idea or API, or just an indifference to the problem. Should we work toward migrating to an Elektra-like system? Something else? Or do most simply find it not worth the trouble?"

Comments

Re:Messes are inevitable

[Just Some Guy]

I agree, with the exception that I think XML is infinitely preferable to some of the hand-rolled workalikes I've seen, and you can use a standard set of tools to parse any particular XML file sitting around.

What's the conceptual differences between

[TopSection]
Setting1 = true
Setting2 = yes
Setting3 = no
Setting4 = false

and

<section name="Top">
<Setting1>true</Setting1>
<Setting2>true</Setting2>
<Setting3>false</Setting3>
<Setting4>false</Setting4>
</section>

except that the latter can be browsed and edited with any editor that understands XML (as opposed to only Vim with the file-format-specific highlighter), can be deterministically validated by generic tools, and doesn't require the program's author to implement his own configuration file parser?

XML isn't a perfect fit everywhere, but /etc is one of the places I think it works brilliantly.