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 <wij...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/874n6ywpvw....@windlord.stanford.edu
>
signature.asc
Description: Digital signature
