Frans Pop wrote: > Guess this makes the earlier cloned bug to debconf more severe. Properly fixing it is going to be tricky. Debconf does it by having a whole class of noninteractive question elements, that are always created for questions that are not displayed. So it's a simple matter of having a noninteractive select element that handles the special case. cdebconf has no noninteractive elements at all. Elements do not know if they are interactive or not, it only creates elements if the question priority warrants it. Also, debconf has tricky code to handle cases like backing up from a visible element to an invisible one. So just hacking in an element that doesn't display will not work; backing up past it will fail. (This is also why it's hard to make cdebconf skip asking select questions with only one choice.) It would be possible to hardcode the special case directly into command_input(). But, there's no guarantee that a question will actually be asked until GO is called, so this could result in cdebconf setting a value when debconf would not set it. The least invasive approach I've been able to think up is to add a separate queue of noninteractive question actions. Make command_input() add to this queue, command_clear() clear it, and command_go() process it, before it calls mod->frontend->methods.go. Even that could diverge slightly from debconf: If two questions are to be asked, the second is a noninteractive select, and the user backs up from the first, debconf will not change the value of the noninteractive select, while cdebconf would. (It could instead handle the noninteractive questions only if the user didn't back up, but that would just make it instead differ in the case where the noninteractive question is first, and the user backs up from the second question.) I think this would be a small enough difference, in an area that is not well specified, that it would be acceptable though, unlike the current glaring difference.. -- see shy jo
Attachment:
signature.asc
Description: Digital signature