Bug#80347: PROPOSED] allow/document use of Debian Configuration management system (debconf)
Anthony Towns wrote:
> > + using only the tools present in the base system.
> ^^^^^^^^^^^
>
> ...which might be uninstalled whenever the user might wish. The "required"
> packages are a better match, although that priority seems a bit flakey
> too, and possibly limiting to "essential" packages is more sensible
> (although IMAO this is what "required" should mean exactly).
Essential is right, so ammended.
> What does this mean about the postinst interface to debconf? Will it
> now stay as a crufty hack forever (or at least the crufty hacks will stay
> for backwards compatability), or...?
My plan is to eventually modify dpkg so it knows about config scripts
and, before it runs the preinst, starts up <a standard exectuable which
will be managed by alternatives or something>, passing it the name of a
file containing the config script. Wichert and I have talked about this
before. It will eliminate *all* the current hacks. There is still the
question of how postinst etc scripts that want to use debconf will talk
to it.
> Probably packages that use debconf would be well server by having
> a Pre-Depends: on something like debconf-2.2 so they can rely on
> a particular version of the protocol being available, however it's
> implemented (debconf, cdebconf), and so that we can phase early, crufty
> protocol versions out, if only by moving them to a debconf-compat package
> in extra somewhere, or similar.
Packages should depend on the version of debconf that implements the
protocol they need. This is the only dependancy that will be checked and
honored especially during preconfiguration right now.. Furthermore the
VERSION command will return the protocol version to the script.
> Apart from the above, seconded.
--
see shy jo
Reply to: