On Thursday 10 May 2007 20:46, you wrote: > Well, we can try to avoid doing it while running inside of installer > but it would be more easy to address using the dpkg-trigger support > that's planned.
The trigger mechanism works only if more than one package is installed at the same time. During installation, grub is installed and then set up *completely separately* by the D-I scripts. So, AFAICT there is no way the trigger mechanism can help here. > Yes but the need of "enabling new features" isn't. Sure, that is why I wrote: > >> - When we add new features as default (e.g. gfxterm), it's not > >> good if they're only default for new users and not existing ones. > >> This way we can't get proper QA for anything we add! > > > > This is only valid for updates, not for new installs. So, you would only have to do this _on upgrades_ of grub-pc, not for new installs. This can be tested separately. Still no need to run anything for new installs. > We, at least for now, won't install grub2 but make it chainloadable > using grub and then user can test it and see if he can upgrade or not. Sure, but that is only in the short term. In the medium term I think you should probably offer the choice using a debconf question: install new grub into MBR or add menu option in current menu.lst to chainload from current grub. And IMO you still need debconf questions to explain what is you are doing as a chainloaded setup is not at all intuitive.
pgpbMy1g3OevQ.pgp
Description: PGP signature
