Thomas M Steenholdt wrote:
Also - Think of the additional error scenarios when init is gconf'ed. The same complexity is added for everything else that adopts a registry based configuration engine (since that engine has to be operational for it to work in the first place) but may not be quite as aparrent.
As I suggested in another message in the original thread, if this is changed, i.e. everything adopts a registry-based configuration *if
one is found* but happily reads plain old configuration files from /etc if not, this problem can be made less aggravating. Personally, a scheme where (a) if the registry or policy daemon is not operational it is supplemented by the configuration in /etc, and (b) said configuration *overrides* unconditionally whatever the registry or policy daemon spits out, would offer the right mix of safety and functionality to give it a try on a non-production host, which seems the sweet spot for Fedora. The scheme might get fancy and differentiate between /etc/foo.conf which overrides unconditionally and /etc/fallback/foo.conf which is read if the registry or policy daemon is not available (and possibly overridden shortly thereafter). For production use, however, the registry or policy daemon *must* preserve comments and be manageable using whatever version control is in use at a site (not everybody uses CVS or SVN); very often, there is a reason behind setting something in a configuration and having to record it separately is just one of the many shortcomings of registry-based approaches. Just my $0.02, Davide Bolcioni -- There is no place like /home. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
