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

Re: Debconf or not debconf : Conclusion

On Thu, Jul 03, 2003 at 04:49:19PM -0400, Joey Hess wrote:
> If I ever add filtering to the notes debconf allows to be displayed,
> notes that refer the user to README.Debian will be at the top of the
> list to never be displayed.
> Of course, I am much more likely to bow to the pressure of notes like
> the one you're apparently adding, and completly disable all notes at
> some point, rather than adding filtering. I don't like arms races.

After seeing multiple attempts to use social pressure to encourage to
stop the flood of debconf misusage, it's at times like this that I
sometimes think Eric Troan really got this part of rpm's design right
(some 7 or 8 years ago) when he completely forbade any I/O between the
install scripts and the user at install time.  As he put it,
(paraphrased since I don't remember his exact wording) if even a small
percentage of packagers indulge their desire to put up dialog boxes,
the system will become extremely annoying.  How prophetic he was ---
or rather, how well he understood human nature.

Everybody believes that *their* package has something ***so***
important to say that they have to tell the whole world about it.  And
perhaps I'm being too pessimistic, but trying to fix this by social
pressure is like trying to shame American soccer mom's into not
driving gasoline-gulping SUV's.  It's never going to work.

If you want to fix the problem, you have the right idea by thinking
that you should perhaps simply disable all notes.  That's the only
solution that will stop the flood of warning messages and noices.
(And perhaps by removing this crutch, packagers will be more
encouraged not to grauitiously break things as the result of package
upgrades, even if upstream does something stupid.)

On a separate but related topic, I think a much better approach would
be to handle configuration as a step entirely separate from the
install phase.  Let the install be entirely quiet, and let packages
have intelligent defaults.  If the package absolutely must be
configured before it can be used, then let it be non-functional until
someone actually calls dpkg-configure (which would be just like
dpkg-reconfigure except that's the only time the questions would be

						- Ted

Reply to: