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

Re: Problems with using debconf in init script...

Matt Zimmerman <mdz@debian.org> writes:

> 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.

We're only reading it if it exists.

I still fail to understand your concern about "being dependent on
access to the filesystem"...

> > > > 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. 

Yes, but not a conffile in the Debian sense (just to clarify).

> 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'm just trying to make things easier.
I've jsut noticed I had to implement something for one of my packages
that might could be reused.

> > > 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'm not talking about any random format, but a simple /bin/sh script
which contains VARIABLE="VALUE" assignments.

Looks like your proposal would handle more generic "any configuration
file". Of course I was never advocating parsing generic configuration

> > > 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

I was talking about the part where debconf's config files and
templates would be automatically generated.

> 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.

I'd say 50-100 lines in debconf :-)

> > > 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.

Mmmh, I hope I'll be more lucky with my system...


Reply to: