Severity: important
Hi Alexander, Le 20 janvier 2017 20:39:04 GMT+01:00, Alexander Kurtz <alexan...@kurtz.be> a écrit : >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. No problem. :-) > However, I believe this >change is not a correct solution, because: > > a) "On Error Resume Next" is (in general) not a good idea. Yes, this was discussed on the team's list and deemed sufficient for now though not a very likable solution. I quickly checked the released versions of desktop-base and it has been doing this at least since Squeeze… (Not that it makes it any better of an 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. Understood. And is not using grub and still having grub tools installed such a common case ? > 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. OK that's a case. :-) I'm not really getting the problem here as I don't understand which other components would break with update-grub updating a grub folder… Not being a specialist I can imagine such cases could exist, though. And anyway I agree with the whole idea that we shouldn't be update-grubing when we don't need to. >> 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 Right, that said it's currently targeted specifically at grub to setup its wallpaper so I can sleep with that. Patches are of course welcome if other bootloaders support similar functionality. >> 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. You mean "activate update-grub" in grub packages ? (Or even "activate-noawait update-grub" would be preferred if I read the doc correctly.) >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. I didn't have dpkg triggers in mind, but it sounds like a nice solution to this problem. I'm unsure we can manage even the "simple" update-grub trigger done for Stretch though. The current behaviour (that I had broken in 9.0.0, and reverted in 9.0.1) has been around for such I long time that I'd personally prefer postponing this change to early in the Buster cycle. If you still feel like preparing the patches for both grub* and desktop-base and coordinating with the grub maintainers, I'll happily accept the change for desktop-base where I have commit rights. Cheers, --Aurélien