[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 - mdz

Reply to: