Re: debconf reconfiguration from postinst of another package

[Wouter Verhelst <wouter@debian.org>]

Hi Jonas,

[re-sending, since my first attempt did not make the list]

Op vrijdag 18 april 2014 12:43:40 schreef Jonas Smedegaard:
> Thanks, but (again) I am sorry if it was not clear: The *question* is
> about *debconf* irregardless of the *example* involving other details.
> 
> Here's another example raising same question without involving audio:
> 
>   * package adduser
>     + asks if home directories should be system-readable
>   * package foo-hippie-desktop
>     + depends on adduser
>     + conflicts against foo-paranoid-desktop
>     + postinst script asks adduser to make homedirs system-readable
>   * package foo-paranoid-desktop
>     + depends on adduser
>     + conflicts against foo-hippie-desktop
>     + postinst script asks adduser to not make homedirs system-readable
> 
> NB! above is again just an *example* meant to illustrate need for
> programmatically changing debconf from another package.

I think part of the confusion here is that you're conflating "configuring 
things through debconf" with "changing package defaults". Debconf does 
allow to change package defaults, but the whole point of debconf is to 
make such changes easier to do for the *administrator*, not for other 
packages. In the cases where such a change in configuration (from 
another package) *would* be useful, we usually already have ways in 
Debian to provide that, but in most cases these are domain-specific (e.g.: 
pam-auth-update, conf.d-style directories, shared debconf questions, etc). 
There are also triggers, but those aren't usually useful for changing 
another package's configuration (more for things like rebuilding a cache, 
restarting a daemon after updating configuration through other means, 
etc).

What you seem to want is a unified and standardized way for one package 
to provide an API for changing things about how the package will function, 
to other packages. While a worthwhile effort, I don't think this is what 
debconf (in its current state, at least) can do. After all, the problem with 
reconfiguring another package in the way you seem to suggest is that if it 
were to be effective for what you want to see realized, it would run afoul of 
the requirement in Policy 10.7.4 that

     The maintainer scripts must not alter a `conffile' of _any_ package, 
     including the one the scripts belong to.

(at least in spirit)

That same section 10.7.4 also explains how packages who wish to change 
configuration files of other packages should work, currently: there should 
be an interface provided by the package through which other packages 
can then change the relevant configuration.

I suppose it could make sense to extend the debconf protocol to also 
support something like that. If done well, the upside of this would be that it 
could abstract away the hard parts (i.e., "how to decide which part 
overrides which other part").

One way this could work is by adding a SETOTHER message (name could 
probably be better), which asks debconf to change a value for a given 
debconf question in another package ONLY if the answer to this question 
was never explicitly set to a particular value by the administrator. This 
would be something like:

SETOTHER example-package/example-question newvalue

(which would translate to db_setother in the shell library)

If the new value is different from the currently-set value, and the 
administrator never explicitly entered a value for example-
package/example-question, then example-package/example-question's 
owner's control and postinst scripts are rerun to synchronise the 
configuration.

Such a system would require debconf to be able to figure out whether 
something was explicitly set, though, which may not be as easy as it 
seems:

- If the question has a default, the value is equal to the default, and the 
seen flag is not set, that probably means the value was never explicitly set 
by the administrator. However, if the value was ever preseeded, it was, 
even if the current value is equal to the default and the seen flag is not 
set.
- If the package uses SET in the config or postinst maintainer script, that 
could mean they're parsing configuration files to synchronize current 
configuration with debconf values, which should probably be interpreted 
as "was explicitly set". On the other hand, if the package uses the 
REGISTER message to dynamically add a (number of) questions and then 
uses SET to change their values when the seen flag is not set, that's 
something more like setting defaults for new questions and hence should 
probably *not* be interpreted as "was explicitly set".

I'm not sure how to deal with that.

Thoughts?

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26