Re: Problems with using debconf in init script...
On Mon, Jan 29, 2001 at 11:01:28PM -0800, Philippe Troin wrote:
> Matt Zimmerman <mdz@debian.org> writes:
>
> > There is some question as to whether it's a good idea for the config
> > script to be dependent on access to the filesystem.
>
> Which should there be a problem here ? We're just _writing_ a file in
> /etc/default ?
Eh? In .config, you'd have to test for the existence of the config file, and
then (if the user wants to "import", I think you called it) read it in to
provide default answers.
> > > Now, this could be folded into debconf, since all the above steps
> > > can be automated !
> > > [...]
> >
> > I think this is going a little far, having debconf actually write the config
> > file for you.
>
> It is _not_ a config file. It's a "selective dump" of debconf's database.
It is a file whose contents change the behavior of a program. It is a config
file. You want debconf to create it. Therefore, you want debconf to write the
config file. I think this is beyond the scope of debconf, and actually writing
(and, less palatably, reading) configuration files should be left to the
maintainer scripts.
> > I would rather have a simple, conffile-like mechanism to keep track
> > of whether or not the user has edited the config file. If so, we
> > ask them whether or not it's OK to clobber their changes. If not,
> > we write our would-have-been config file to
> > config-file.dpkg-something where they can examine it and take what
> > they like.
>
> Did you read my proposal ? That's exactly what you propose, except
> that if the file has been changed along some rules (namely, only
> variable values have been changed, and these new values fit debconf's
> allowed values), then nothing is lost and the manually changed values
> can be imported into debconf.
Yes. I am specifically saying that I would like to exclude that part of your
proposal, and ONLY deal with tracking whether the file has been changed, like
the current conffile mechanism. I don't think debconf, or anything else other
than a few sadistic maintainer scripts, should be trying to read (and convert
between) application config file formats.
> > I started implementing something like this, using a set of shared debconf
> > templates and some debhelper magic. It has the following parts:
> >
> > - A debconf-templates package, containing the templates to use.
> > These contain substitution variables for the name of the
> > configuration file and the name of the package, and are used for
> > prompting the user and storing the md5sum.
> >
> > - A debhelper script (named?) which takes the names of these kinds of config
> > files (they need a name) and generates code for .config and .postinst
> >
> > - Some modifications to dh_installdeb to allow substitution into .config
> [...]
> It looks like very complex to me (automatic script generation).
> My proposal (again :-) only involves adding some extra headers to the
> template file.
>
> The debconf changes themselves are quite minimal I would think.
> I might even look into it tomorrow :-)
It's no more complex than using dh_suidregister.
In debian/rules:
dh_newhelperprogram etc/mypackage/mypackage.conf
That's all the user would see. I am talking about implementation. Your
proposal will require a lot of extra code in debconf, I'll wager. Mine
requires only the simple components above, some of which I've already written.
I would argue that your proposal will require more code, and more complex code.
Let me know what you find out.
> > Once these are in place, making this work is as simple as adding one
> > line to the rules file. The only problem I encountered was that for
> > things to work as they should, the debconf-templates package has to
> > be installed before dpkg-preconfigure is run. I know no way to
> > guarantee this, apart from having the templates included in debconf.
>
> That might be a problem, but maybe your templates could be included
> with debconf...
joeyh is against this because he doesn't want to maintain them, and I can't say
that I blame him. Come to think of it, I think he suggested that debconf
depend on the templates package, and that could very well be sufficient. I
don't know how things fit together at initial installation time, with
debconf-tiny.
--
- mdz
Reply to: