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