Re: dotdee: a proposal for improving conffile management in Debian
Hi!
On Fri, 2011-04-29 at 11:03:39 -0500, Dustin Kirkland wrote:
> IN PRACTICE
> Once integrated with dpkg, I'd like dotdee to be a utility that human
> system administrators could run to manually turn a generic conffile
> into a ".d" style configuration directory, such that they could append
> their own changes to some numbered file in the dotdee directory, avoid
> the interactive dpkg-conffile-changed prompts.
This does not take into account admins dropping the file under the
directory and then the package picking up the new file automatically,
they have to generate it manually afterwards. You mention apache, and
its framework (another good example is pam), but I don't think that
much is usually needed, just having the application support .d config
directories should be enough, and that usually implies less than around
50 lines of C. This also benefits upstream and all its downstreams,
and people building directly from sources. Also this implies the
configuration file cannot be directly edited, and if done so the
changes will get lost on the next regeneration.
As a counter example, a package that provides something similar to
dotdee, there's exim4. And while I think the efforts by their
maintainers to provide a more manageable way to configure it are
worthwhile, it's also one of the reasons I always use the user managed
single concatenated file. It's too annoying modifying a file and
forgetting to run update-exim4.conf. At some point in the future I
should just sit down and propose a patch for native .d support.
In addition the combination of "diverting" the conffile, merging it
back by a tool, and then using alternatives, seems pretty convoluted
and a quite possible source of confusion and fragility.
> More importantly, I would like one package's postinst maintainer
> script to be able take another package that it depends upon and turn
> its conffile into a dotdee managed file, such that it could append or
> prepend configuration information necessary for proper operation.
> This, of course, would require significant buy-in from Debian, and
> entail various appropriate policy updates.
That in essence is just diverting conffiles, and I think it's at least
for distributions a bad idea, for personal use I don't see any problem
with it though. If a package needs to modify the behaviour of another
one it should do it in concordance with the other package, and not
under its feet. Usually in that case the package provides an interface
to modify the configuration file, or provides a .d config directory.
That should currenty be described already in policy.
> In terms of supported configuration file types, dotdee would
> eventually need some code for handling some particular configuration
> file types. The current, basic implementation works well for
> sequentially evaluated file types (like sourced shell scripts), python
> config parser, and even windows ini file syntax. On the other hand,
> something like XML would not immediately work in the current dotdee
> implementation. For that, I've thought a bit about a similar
> approach, constructing the conffile from a quilt directory of numbered
> patch files. If you're interested in this approach, I can describe
> that in more detail, too, and perhaps implement another prototype.
To be honest, that sounds like a hack to me. :) But if you are
interested to still go this route, then maybe Config::Model might be
useful to you? In any case, the application handling the configuration
files is in the best place to know its internal layout, and how to
handle it.
So all in all, I don't think this is the right way to solve the problem
you describe. And while I also think the conffile handling in dpkg can
be improved, in this case the correct solution seems to me, to be to
add .d support to the needed applications.
thanks,
guillem
Reply to: