Hello list and Joey, about a year ago, I reported a wishlist bug on debconf (#690390, more details below). I received a reply which seemed to say you agree with me on all points except implementation. I asked why you didn't agree on that, since it would make many things better, IMO. Unfortunately you didn't reply to that. (No problem; I suppose you were busy, and I didn't ping until this e-mail.) I'm sending this to -devel, because I think it would be useful to have more opinions. I'm sure the readership will come up with viewpoints both of us hadn't considered. For those who don't want to read the bug log, here's a summary: Debconf caches answers that users give it, and provides those as defaults the next time the question is asked. But almost always, the answer is also stored in a configuration file. Which means there are two places holding the same info. If they are out of sync, most likely the admin has edited the config file. This means that the value in there should be used, not the cache of debconf. Packages that use debconf's cache instead, are rightfully accused of using debconf as a registry, and should be fixed. What this means, is that every package which asks debconf questions (and stores the answers in a configuration file) will need to: 1. Parse the configuration file, if it exists, and set the values as defaults before asking the questions. (in the config script) 2. Update the values in the configuration file. (in the postinst script) Currently, many packages only do 2, and that is wrong. Now I'll quote a piece from the bug log, because I think it's written clear there: On Sat, Oct 13, 2012 at 01:27:31PM -0400, Joey Hess wrote: > Bas Wijnen wrote: > > The proposed solution is to add functionality to debconf, which can > > read and edit config files. > > debconf already contains this functionality. It's called a config > script. [...] If I understand you correctly, you are saying that each of those packages should implement parsing code for it in its config script. My point is that this results in needless code duplication. Therefore I would like to move this parsing code to debconf, so most packages can simply use a function call. Packages which have more complex config files must still implement parsing code for it themselves. End of the quote. The most straightforward and non-intrusive solution would be to create a new package containing this parsing code and let all packages that want to use it depend on that. However this doesn't work. From debconf-devel(7): > Note that the config script is run before the package is unpacked. It > should only use commands that are in essential packages. The only > dependency of your package that is guaranteed to be met when its > config script is run is a dependency (possibly versioned) on debconf > itself. Note that this means even a Pre-Depends wouldn't do the trick. The only thing that would work, would be to add it as a Build-Depends and mangle the config script at build time. It sounds ugly to me, but I suppose it can be done. It could even be a debhelper add-on to hide the uglyness. Would that be a good thing to do? Are there other things I'm missing? Is this a non-problem, that doesn't need a solution? Thanks, Bas
Attachment:
signature.asc
Description: Digital signature