Re: debconf as a registry
On 10/17/2014 01:41 PM, Bas Wijnen wrote:
> Getting random packages from apt-cache rdepends debconf shows:
>
> - several packages that use debconf for questions that are only about
> actions that don't need to be (and aren't) stored in config files.
I previously thought that it was the case. Then thinking about it, it's
often possible create configuration files for the sole purpose of being
policy compliant and store values out of debconf. The /etc/default
folder is a good place for that.
I see only one case where the output of questions from Debconf should
not be stored: when it makes sense to *always* prompt (eg: when the
maintainer really wants the question to be asked each time the package
is upgraded). I do maintain packages with such a case.
> - cxref uses ucf in postinst. This doesn't violate policy, but does (in
> case of local changes) give the wrong default in the debconf question,
> and an annoying "do you want to overwrite local changes?" after
> answering the question.
Without looking, this sounds like a "postinst modifies a CONFFILE",
which indeed is a policy violation.
> - esmtp starts by asking if you want to overwrite your config and
> refuses to be configured by debconf if you don't. Also
> policy-compliant
This is debatable. To me, it doesn't make it policy compliant just
because the frist debconf prompt makes it possible to not do anything.
> - dvi2ps does something I don't understand... It asks questions but
> never runs db_get. Presumably it pre-seeds some other package?
Its looking like it doesn't need to do db_get. The only debconf
templates which it has are of type "note", so it's not taking any decision.
> - ibam depends on debconf but doesn't seem to ask any questions; it
> doesn't even have a config or postinst script.
>From the debian/changelog, it's looking like a leftover from previous
versions, and that it shouldn't depend on debconf (anymore). I'd say:
feel free to open a bug (of the lower severity).
> - gpm does it right, in surprisingly few lines.
> - grr does it wrong.
Yup, it should read the configuration file first.
> This tiny investigation shows that most of the packages that handle
> configuration files are either doing it in a way that is not
> user-friendly, or that uses significant code in the config script. Both
> of those cases would benefit from taking that code out of the source (if
> it was there) and replacing it with an include statement.
As I wrote previously, this may only happen if we decide to have such a
library as essential, otherwise this forces to use pre-depends, which
isn't good.
I don't think investigating only 6 packages grants you the rights to
write "most packages". Please be careful. This doesn't mean that I do
not agree, in fact, I do agree with you that we would benefit from
having this kind of library in Debian.
Maybe we could even have what you're talking about directly in Debconf
itself? I think it would make a lot of sense. If you want to work this
out, please investigate the possibility to enhance Debconf directly,
without needing to ship any supplementary lib.
>> Then such a library *must* be marked as essential, and installed by
>> default, otherwise it would break the install workflow.
>
> No; it's a _static_ library. It is included in the config script at
> package build time.
That's what I'm currently doing in all the OpenStack packages, and I'm
not satisfied with this approach. I very much would prefer an
enhancement of debconf itself.
> This means every binary package using it will have
> a copy of the code in its maintainerscript.
Which isn't nice.
> A change in the library requires a rebuild of all the packages for
> the change to take effect.
Which doesn't scale archive wide if you find a bug.
> That's not ideal, but better than marking it as essential, or making it
> part of debconf (which would also work, but requires Joey Hess to accept
> it, and so far he refuses to even acknowledge that there is a problem;
> even if he would, I find making it a separate package a more elegant
> solution).
I don't agree with what you wrote above. Making it essential is a much
better approach. As for Joey Hess, he is a very reasonable person. If
you come with a patch which is well written, and does enough to be
helpful, I'm sure he'll accept it. If it's just bad, then probably he
will refuse. I've seen this type of pattern multiple times with him.
>> Ok, you have a repository. But which package should we look into?
>
> Oops, sorry and thanks for the reminder. It's dh-parseconfig:
> http://wijnen.dtdns.net/archive/unstable/{all,source}/dh-parseconfig*
>
>> As for parsing files, I don't think using perl is a great idea.
>
> The perl script only pastes the file into the config script.
I've done this with a few lines of shell script. If that is what you
want me to look into dh-parseconfig, then I don't think it's worth
looking at.
> The actual
> parsing is done by a script in the language that config is written in.
> That means there must be an implementation for every language (/bin/sh
> being the most important) and every common file type (ini and csv
> probably being the most important).
>
> Note that none of those parsing libraries have been written yet. I'll
> probably take some code from pioneers as a starting point.
I've written this type of shell script in shell already. Though the
issue is that it's currently very slow. You can have a look into
openstack-pkg-tools, which holds the logic. However, really, the
pkgos_inifile (inside pkgos_func) would need some rework to make it go
faster. And I mean it: A WAY faster, not just stupidly horribly slow
like it currently is. The ways to do it would be:
- Using awk (as a complete replacement, not just a little here and there)
- Try to avoid using too many forks, and use more shell embedded
functions whenever possible
- Review all the algorithm, and think about something smarter and
faster. Something which doesn't do an event on all lines from the config
file would be much better (using grep to divide an ini file into
sections for example would speed up things a lot).
I haven't had time to work it out, but it shouldn't be so hard to do.
Anyway, this type of code would be much much nicer if written in C/C++,
and included in debconf itself.
> I don't have a bug tracker yet, but I can upload this to unstable if
> people don't complain too much about the code. ;-) Then the bts can be
> used for feature requests (and bugs of course).
Please don't upload this type of experimental software to Sid just right
before the freeze. Please use experimental.
> The library is meant to make common operations easy. If a package has
> special needs, it must still implement its parsing by itself.
Well, no. What's the point then? To make your piece of software useful,
you must address as many cases as possible.
> For example, if there are functions for "read
> value from section", "delete value from section" and "write value to
> section", it's only one if-statement (use value from new section if
> present, otherwise from old section; writing doesn't suffer because you
> wouldn't write to the old section anyway, you can just delete the old
> value).
Yeah, but then this can be implemented within the library, on top of the
functions you mentioned.
Cheers,
Thomas Goirand (zigo)
Reply to: