On Wed, Jul 09, 2003 at 04:43:11PM -0500, Manoj Srivastava wrote: > >> Eh? Suppose I do echo "" > config file, you are going to blow my > >> changes away and "recreate the configuration as the package deems > >> fit"? > >> Packages ought not to rely on the configuration file to provide > >> sane defaults. > > Is this in policy somewhere? > Umm. Have we totally lost the ability to add 2 + 2 together, > without it being in policy? Since users are allowed to change > configuration files, packages need to be very liberal in what they > expect. > And if you can see, I said ought, not must. Well, "ought" means "should" -- you're making a recommendation that not only isn't present in policy, it seems at odds with the whole concept of conffiles. Conffiles are a mechanism for providing "sensible defaults" for package configuration; if packages should not rely on config files for sane defaults, then packages should not use conffiles. > > I know that applications must not depend on environment variables > > for sane defaults, but I don't remember anything about not being > > able to depend on config files for this. I think depending on a > > config file for sane defaults is much better than heavily patching > > an upstream binary for the same effect. > Now, there is no constraint on how the package behaves when > faced with a malformed configuration file -- exiting with a > diagnostic is not unacceptable. And is it acceptable to consider an absent config file "malformed"? > > As to the question of whether rm /etc/config/file should be > > respected, c.f. the behavior of update-rc.d (a policy-mandated > > interface), which regards the total absence of symlinks as an > > indication that they should be re-added. > But one ma delete all but one symlink anf not have them > replaced, or delete a file from /etc/init/d and not have symlinks > recreated. > > There's lots of precedent for this sort of config file handling, and > > I'm not sure that it's particularly beneficial to require packages > > to respect the removal of a config file. > Packages already have to deal with effectively removing > configuration files -- (the echo "" device). How is it so different > to also expect them to respect non existent files? (even if the > response is making the package a nop) The most straightforward test for a postinst to use in deciding whether to create a non-conffile config file is 'if [ ! -f /etc/config/file ]'. I expect there are many packages that currently use such a test. If this is unacceptable, there are a lot of bugs that need to be filed; and I don't see that doing a bunch of work to file and fix those bugs (instead of condoning this exception) brings tangible benefit to our users. -- Steve Langasek postmodern programmer
Attachment:
pgpEV5dVVX9iX.pgp
Description: PGP signature