Hi! On Thu, 2017-01-19 at 22:05 +0100, Aurélien COUDERC wrote: > Thank you for your detailed bug report and analysis. > This looks a lot like #843727 [0] to me, although not for the same use case. > > Would you care to test 9.0.1, already in sid that should fix this problem ? > The following change was done : > 208: update-grub || echo "Updating grub failed, report success anyway!"
I am sorry, I had not noticed bug #843727. However, I believe this
change is not a correct solution, because:
a) "On Error Resume Next" is (in general) not a good idea.
b) It is still a GRUB-specific solution. People use a whole bunch
of different bootloaders to start Debian, GRUB is just one of them.
c) It will cause really subtle bugs under some circumstances.
Let me explain c): Assume that a user has the grub-pc package installed
and GRUB is installed to /boot normally. At one point, the user decides
to remove the grub-pc package (and only that) and use a different
bootloader. Everything works, but the files under /boot/grub are of
course still there. Now your package comes along and runs update-grub
which happily modifies /boot/grub even though the user explicitly
removed the GRUB automation package.
> I'll merge the 2 bugs after confirmation that it works for you.
I agree that your changes fixes the immediate problem. But I really
think there are two fundamental issues with desktop-base calling the
update script of one specific bootloader:
(1) It's surprising to the user (and the maintainers of other packages)
(2) It will only work with GRUB
> If you know of a better and robust way to detect if grub is being
> used, advice is welcome.
There is a better way, dpkg triggers [0-3]. There's even a
corresponding bug in GRUB about it [4]. However, nobody really seems to
care, so not much progress has been made.
Maybe you could talk to the GRUB maintainers and convince them to add a
"interest update-grub" trigger in the grub-pc and grub-efi packages.
Then GRUB's postinst would run the update-grub script and all your
postinst would do, is issue a "dpkg-trigger update-grub" call. Of
course, it would be even better to find a generic solution for all
bootloaders (e.g. a generic "update-bootloader" trigger), but I believe
that it's too late in the release cycle for this.
What do you think?
Best regards
Alexander Kurtz
[0] https://manpages.debian.org/jessie/dpkg-dev/deb-triggers.5.en.html
[1] https://manpages.debian.org/jessie/dpkg/dpkg-trigger.1.en.html
[2] http://eric.van-der-vlist.com/blog/owark/473/
[3] https://wiki.debian.org/DpkgTriggers
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481542
signature.asc
Description: This is a digitally signed message part
