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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140507093423.ga20...@grep.be
