Re: Problems with using debconf in init script...
Anthony Towns <aj@azure.humbug.org.au> writes:
> On Mon, Jan 29, 2001 at 05:41:08PM -0800, Philippe Troin wrote:
> > > > What happens if someone makes some changes to /etc/default<service>
> > > > and than dpkg-reconfigure <service> is ran ? Overwrite manual changes ?
> > > Same thing as happens if you've made manual changes to any other config
> > > file that uses debconf values before running dpkg-reconfigure.
> > > Exactly what that is isn't entirely clear, but it's a known problem and
> > > a couple of solutions were discussed in a recent thread... It's not a show
> > > stopper, though.
> > Uh, loosing information is a show stopper to me :-)
>
> Well, there are (afaicr) a few ways of reasonably handling this situation:
>
> 1) Not asking any questions, or using any debconf values if the
> /etc file has been modified
> 2) Using the debconf values when --reconfigure'ing (but not during
> normal upgrades)
> 3) Having an additional prompt if both the debconf and the /etc
> values have changed
>
> I don't think there's any real consensus on which of these is best.
What about (4) which I implemented for am-utils:
4) The debconf config script writes the values it needs as a shell
script to /etc/default/<package>. Once the file is written, its
md5sum is stored inside debconf.
When the debconf config script (re-)runs and finds the
/etc/default/<package> file, it md5sums it, and compares the sum
with the stored one.
- If they're equal, there's no need to load the
/etc/default/<package> file.
- If the sums are different (file has changed), the user is
asked to choose between:
1. abort: leave everything as is.
2. forget: forget about the manual changes to
/etc/default/<package> and use the debconf values.
3. import: try to import the values back. The config
scripts validates all variables. If all variables are
valid, then this configuration is set as debconf's
defaults. Else, the user is asked again what to do
(abort, forget, import).
Of course, the init script uses /etc/default/<package>.
Now, this could be folded into debconf, since all the above steps
can be automated !
What I suggest, is add the following (optional) fields to every
debconf template:
* Export: boolean, whether or not to export the value to the
/etc/default/<package> shell script file.
Alternately, "Export" could be dropped in favor of a "Export-To"
tag giving the path of a shell file to write to. This way, debconf
scripts could write values in different files.
* Sh-Description: random multi-line string to be written to the
shell script file as comments. Rationale: the regular description
does not fit since it could be too descriptive or adapted to the
interactive config script. Sh-Description might also contain some
comments which would not make sense in the context of the
interactive script (like "value foo is only used if value bar is
true").
When debconf starts up:
* after loading the database, if any template has the "Export" tag
(respectively "Export-To") it checks whether or not
/etc/default/<package> (the files listed in the "Export-To"
fields) exist(s).
* if the above file(s) exist(s), its/their md5sum is compared to the
one(s) stored in the debconf database.
* for every changed file, a menu is printed offering either to
import (the file), discard (the changes made in the file), or
abort.
* for every file which has to be imported, debconf would then
validate the contents since it knows what the field is supposed to
be.
* if some values are invalid (for example a string "junk" for a
boolean value), the whole import fails, and the user is asked what
to do (import, discard or abort).
* if all values are valid, they then override the defaults in the
database.
* normal debconf processing occurs
* as a last step, debconf checks if any template has the "Export
tag" (respectively "Export-To"). If yes, all the values marked
with the Export* tag are written to the /etc/default/<package>
file (the Export-To file).
Every entry in the shell script could be of the form:
# <Variable name> # foo/bar
# <List of legal values> # boolean ("true" / "false")
# <Sh-Description value> # If bar is set, then debug is on
<var>="<value>" FOO_BAR="true"
All written files are md5summed, and the sums are stored in the
debconf database.
Basically, it's "smart" conffile handling in debconf.
Joey (if you're reading me), what do you think ?
Phil.
> > Why did you take the discussion of d.devel@l.d.o ?
>
> *sigh*
I hope I didn't push you too much :-)
Phil.
Reply to: