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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
