Op woensdag 7 mei 2014 12:19:31 schreef Philip Hands: > 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 ;-) ) And the wrath of people preseeding their installations. But yes, I suppose that's true. [...] > 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 -- I suppose that approach could work. It would also solve the problem of not being able to figure out which question "has been explicitly set" by the maintainer: define a new set of "public" questions, assume all current questions are not in that set, and have a flag on the public questions that would indicate whether the administrator, through whatever means, ever explicitly set it to a particular value. Then debconf could ignore SETOTHER commands for questions that either are private or are public questions which the local administrator ever explicitly set to some value. > 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. I don't think debconf needs to care about that, though. A maintainer "just" needs to make sure that whenever they change the meaning of a public debconf question, they need to change the name (possibly by incrementing an embedded number in that name). That's something we should document, but which would be pretty hard to enforce, I suppose. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Attachment:
signature.asc
Description: This is a digitally signed message part.