Re: Top 5 things that aren't in Debian but should be :-)
On Thu, Feb 05, 2004 at 08:44:53AM -0600, Steve Greenland wrote:
> I'm all for uniformity, I'm against expecting or even encouranging
> packages to use debconf rather than providing sane defaults in
> conffiles.
>
> And no, low priority questions in debconf are NOT a suitable solution,
> until you figure out a way that is *at least* as good the current
> conffile mechanism in preserving local modifications while allowing
> package updates to configuration. It's a hard problem. I'd guess[1] that
> currently about 25% of the debconf using packages get it wrong, and
> overwrite local changes on a regular basis. Another 50% avoid this by
> simply never integrating upstream changes on upgrades, even if I've not
> touched the defaults.
>
> If people want pretty GUI for configuration, that's fine. If it's
> consistent with the existing debconf UI, even better. But if it
> interferes with installation by asking tons of questions that 98% of the
> users don't care about, and screws up ongoing maintenance and upgrades
> of the system, then it needs some more thought. And currently, debconf
> and dpkg-reconfigure are not up to the task. (Or rather, getting it
> *right* is too hard for maintainers, using only those tools.)
Steve, we're discussing two totally different things. They both use
debconf, but you're talking about the stuff that runs at install time.
All the questions, basically the way debconf is used now. It can also be
used as a UI that is *completely separate* from installation. That's
what configure-debian is, and will continue to be. There is absolutely
no reason to preserve local changes to the user's config if they are
explicitly using the program to change that config. Yes, for
installation of packages, the automated process shouldn't touch the
user's system if it can be avoided, but for apps that are run to
acutally make those changes, they should be voided. Just because the app
uses debconf as its UI does not change this.
- David Nusinow
Reply to: