I think that we need to sort this out before lenny. I'm beginning to doubt that the apt and aptitude bugfixes that would allow cancellable progress bars are going to happen anytime soon. I'm inclined to go ahead and handle the upgrade as best we currently can, even if it's imperfect. Closing a security vulnerability window is more important then perfection. There are numerous potential technical issues to deal with: a) dist-upgrade might screw up and remove important packages, or fail So it would need to use safe-upgrade, although this might fail to get all security upgrades, in some situations. b) debconf prompts We'd need to use debconf-apt-progress to proxy them to d-i. c) conffile prompts Seems we'd have to use --force-confnew. Of course anything that triggers a conffile prompt in this situation is buggy anyway. d) tty prompts Any tty prompts by packages installed by debootstrap or base-installer would have to be treated as grave bugs as they break d-i. e) daemon starting We already deal with this in pkgsel.. f) dependencies on running daemons/booted system/whatever This kind of thing would have to be treated as RC bugs in the packages since it would break d-i. g) extraneous/absurd prompts One such is the kernel module upgrade prompt. Just because d-i is running $KVERS does not mean that upgrading $KVERS in a chroot should display this prompt. The kernel package would need to be modified to detect this, and avoid the prompt. -- see shy jo
Attachment:
signature.asc
Description: Digital signature