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

Re: [custom] Custom Debian Distros need the help from debian developers

On Sun, Feb 15, 2004 at 10:04:01AM +0100, Petter Reinholdtsen wrote:
[debconf preseeding makes mass-configuration easy]
> What should we do to make sure all the packages we need to configure
> at install time are configurable in a standardized way, preferably
> using debconf preseeding?

Hm. Perhaps debconf preseeding isn't the right tool, then.

It appears to me that debconf currently has two entirely distinct types
of users, with sometimes conflicting requirements. On the one hand,
there're a number of people that want to install their personal system.
These people want to be asked something when a package wouldn't work
without configuration and doesn't have reasonable defaults, but they
don't want to be asked a gazillion of questions. Hence, the number of
questions should be low for this class of users.

On the other hand, there's a bunch of system administrators that want to
configure a high number of their systems in the same way. They don't
actually want a high number of questions; what they want is flexibility.
Since in the case of debconf the flexibility increases with an
increasing number of questions, these people want more questions; but
since they don't actually go and manually answer each of them, it is not
the case that they'd care if there were less questions, as long as the
flexibility remains.

Once way to fix this issue would be to use part of the debconf API,
i.e., the priorities, where questions rather aimed to sysadmins -those
just meant to make a flexible enough configuration using debconf
preseeding possible- are given priority 'low', while questions meant to
make the initial installation a bit easier are given a higher priority.

The problem with this approach is that it doesn't really scale all that
well. It requires glue code between the debconf database and the
packages' configuration files, which will be nontrivial if the
configuration file format isn't too trivial either. That's not much a
problem when debconf is only used to fill in the blanks for
configuration parameters where defaults aren't reasonable; but it
becomes more of an issue for situations that require a higher level of
flexibility. When there's more code, there's also a higher probability
of bugs, not to mention the fact that the code has to be written first,
which takes up a considerable amount of time.

My question is: why bother? What sysadmins really want is a way to get
configuration on the target system without having to do much about it;
debconf is a way to do that, but maybe not optimal, given the above.

Perhaps it's better to do it differently. One way could be to add a
general system to distribute configuration files; e.g., adding a hook to
dpkg that would check whether a certain option has been set, and that
would kick in when a conffile is being written to disk; if that dpkg
configuration option has been set, instead of getting the conffile out
of the .deb, dpkg could then retrieve the configuration file from a
different location, such as from a server that would contain it, or from
a CD-ROM or so.

How's that sound?

Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.

Attachment: signature.asc
Description: Digital signature

Reply to: