Hi Michael, I'm interested to know what you would recommend we do instead of erroring out in this first case. Should the user not be allowed to cancel the debconf prompt? Should it immediately respawn the prompt? Should the cancel be treated as equivalent to the default option?
I have a hard time accepting that any of these options are an improvement over the current behavior - to me, "cancel" translates to "defer this until later", which is exactly what happens now with all the negative side effects - but I'm certainly happy to consider ways that this can be improved and help to implement them. For the second case, I agree that it's a bug. What would you advise we do here? Some options that come to mind would be to suppress the shell option based on the debconf frontend, to reword the template to always tell users the shell will appear in the background, or to unconditionally drop the shell option. -- ucf UI issues can cause upgrade failures https://bugs.launchpad.net/bugs/243809 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
