As I wrote in the blend thread, reading through bug #311188 raised some new questions for me about this one. I will start by explaining the original problem again; it seemed to me that it wasn't understood by everyone. Then I'll add some new thoughts based on that bug. Finally, I present some code to solve the problem, on which I welcome feedback. ========= Explanation of the problem ========= Policy says (10.7.3): local changes must be preserved during a package upgrade However, configuration is stored in two places: in the configuration files in /etc, and in debconf's "configuration space" (which I'll call debconf's cache). The expected way that things work is: - On package install, a debconf question is asked and the answer is stored in debconf's cache. - Later during the same install, the cached value is copied into the configuration file by postinst. The problem appears on upgrade: debconf will again be called, and the question is whether or not to ask a question, and if so, what the default answer should be. And if not, what the value in the cache should be after not asking the question. That latter question is easily answered: it must have the same value that would have been the default if the question was asked. For the default answer there are three options: - The default that was supplied by the package. This is obviously wrong, it must only be used if there is no other data. - The value from debconf's cache. - The value from the configuration file. Since debconf's cache is a cache, not a registry, the latter is the correct answer. Debconf's cache MUST BE IGNORED if there is a configuration file. In practice it often doesn't matter, because the values are identical. But when they aren't, the admin has made local changes and they must be preserved. So debconf needs to read configuration files, but it doesn't know how to parse them. So it does the only thing it can: it uses its cache. Which means that each and every package that uses debconf must make sure that they read the configuration files and update debconf's cache _before_ running debconf. And most of them don't do that. (It also involves a significant amount of nontrivial code, which we really shouldn't want to see duplicated in every debconf-using package.) In fact, the debconf specification[0] even suggests that using debconf's cache is perfectly fine. The paragraph on "The configuration space" explains how two packages that share a configuration value can use the same value in the cache. But the important thing is that they should share a configuration file (as described in policy 10.7.4). While sharing a cache key is a good idea, because it avoids a duplicate question if both packages are installed simultaneously (both config scripts are run before both postinst scripts, so the shared configuration file is not updated when the second config script runs), that is really a minor issue. In the quote below my text, Russ agrees that all the packages are buggy, but he doesn't address the issue of how those bugs should be fixed. IMO telling all those maintainers to copy a significant piece of code into their config script is a bad idea. [0] https://www.debian.org/doc/packaging-manuals/debconf_specification.html which is linked from policy 3.9.1. ========= New thoughts inspired by #311188 ========= This bug is about debian-edu which needs to configure the system for its users. Because it wants to be a Pure Blend, it uses packages from the official archive. That's very nice. However, those packages all have their own ways of storing their configuration. So debian-edu has a similar problem as debconf: it cannot change the configuration of the packages in a policy-compliant way. Debconf doesn't know how to edit the files; debian-edu does know (because it uses code that is targeting specific files), but isn't allowed to do it. The solution would be for every package that debian-edu wants to configure to either add debconf questions which can be preseeded, or to add update-* scripts to allow those configuration files to be shared. If debconf is used properly, as described above, preseeding the cache should only work while the configuration file doesn't exist yet (otherwise the cache is overwritten before it is used). For this purpose, I consider that a feature, not a bug (because it means the admin can trust that the system doesn't decide to change things seemingly at random). However, regardless of which option is chosen, the packages require significant code to make them work. On the bright side, the result of that work is that they can be configured with debconf, which means it improves the quality of Debian. ========= Conclusion ========= The above problems are solved by my plan to create a "static script library", which is included in config scripts at package build time. This library would define functions for parsing common config file formats, and can be included in config scripts with a line similar to ##DEBHELPER##. This has the benefit of solving the problem, without causing the problem of adding lots of duplicate code to the soures. If blends use pre-seeding, d-i will need some way to make sure that the blend package (which does the pre-seeding, I would imagine) is configured before all others. But Jonas has a point: when using this approach, it means that "You don't really have a Debian Edu system when installing it on a Debian system" (but you do when selecting it during systme install). If they instead would edit configuration files using public interfaces, the script libraries will need to be available on the system so the update-* scripts are as easy as possible to write. I would personally prefer the pre-seeding option, but regardless it may be a good idea to use this opportunity to make writing update-* scripts a trivial excercise. ========= Code ========= Oh yes, and I have some code ready for feedback. I haven't written the script libraries yet (and I want others to write some of them), but I have written the debhelper module for using them. I have set up a mini-dinstall repository where you can get the binary and source packages: deb [arch=all,amd64] http://wijnen.dtdns.net/archive unstable main deb-src http://wijnen.dtdns.net/archive unstable main (Please ignore problems with the keys; I'm still getting it to work right.) The code is derived from dh-autoreconf and it is the first ever perl program I wrote. So please don't insult me, but also don't hold back when you see things that need to be improved. :-) Thanks, Bas On Tue, Nov 26, 2013 at 06:16:19PM -0800, Russ Allbery wrote: > Bas Wijnen <wijnen@debian.org> writes: > > > 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. > > And those packages are all buggy, and whenever you encounter one, please > do file a bug and get that package fixed. I've fixed this bug in various > packages over time, including some of my own. > > I agree with Joey that a package's own maintainer scripts should be > responsible for parsing the package's configuration files. There are too > many possible cases that will come up over time, such as a need to migrate > one value to another, and the package should be an expert in its own > configuration syntax. > > It's the package's responsibility to read debconf-based data back from the > persistent store and treat that as a maintainer override. Policy is quite > explicit about this. > > -- > Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/> > > > -- > To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > Archive: http://lists.debian.org/874n6ywpvw.fsf@windlord.stanford.edu >
Attachment:
signature.asc
Description: Digital signature