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
files...
> > > 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...
Phil.
Reply to: