[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#162120: Support #162120



On Wed, 9 Jul 2003 17:35:44 -0500, Steve Langasek <vorlon@netexpress.net> said: 

> 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 think you are mistaken in what conffiles are supposed to do,
 and how they behave. Let me see if I can express this correctly.

	Given any conffile, with N configuration directives, a user
 is allowed to delete a configuration directive, so there are N -  1
 directives left. 

	Rinse. Repeat. So you may be left with a configuration file
 with no configuration directives whatsoever. Ideally, the package
 should ahve sane defaults without relying on an external file that is
 supposed to have user modifications -- that is simple defensive
 programming practice. 

	Now, if it really is a conffile, and you remove it; it shall
 not be recreated for you the next time you upgrade the package. If
 the maintainer has not made any changes in the version packaged, you
 shall not even be asked a question.

	So, I repeat: If you remove a conffile, it is not
 regenerated. (IT IS NOT REGENERATED). You are not even asked about it
 unless the implementation has changed in the package.

	Get it? See how what I propose actually models what has
 always happened with 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"?

	Perhaps. Depends on the application. But malformed config
 files are still not edited in  place, or replaced.

	manoj

-- 
"All the people are so happy now, their heads are caving in.  I'm glad
they are a snowman with protective rubber skin."  They Might Be Giants
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: