[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debconf reconfiguration from postinst of another package



Wouter Verhelst <wouter@debian.org> writes:
...
> 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

The trouble with that is that the question is implicitly tied to the
version of the other package.  At present a maintainer is free to change
all the questions in a package's debconf on every release (assuming
they are willing to live with the wrath of the translators ;-) )

> (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?

The debconf questions for packages have a tendency to start out simple,
and then add additional options as people request additional
configuration subtlety, or as the package grows new features.  If we
allow people to set up implicit dependencies on the particular meaning
of a question in a particular version of another package, we're just
asking for the thing they think they're setting to be shifted into some
more recently introduced question.  This seems like a road to chaos.

I think there would at the very least need to be some way of ensuring
that the target package's maintainer knows that other packages are
relying on the current meaning of some questions.  Perhaps we could
distinguish between public and private questions, where declaring a
question public would allow it to be manipulated by a third party, but
would also carry with it an obligation to maintain it's meaning in a
backward compatible manner -- we could perhaps give public variables a
version number, or only allow questions with such a version number as
part of their name be manipulated from elsewhere.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://ftp.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND

Attachment: pgpgk1z3LlJ2I.pgp
Description: PGP signature


Reply to: