we should create a grub2-common or grub2-tools package (like FC does) Most files are identical (binaries, translation catalogs, most of man pages, /boot/grub2/* ...) eg: FC split common tools in grub2-tools that is required by both grub2 & grub2-tools: http://rpmfind.net/linux/rpm2html/search.php?query=grub2-tools&submit=Search+... Obviously that means grub2-tools should conflicts against older grub2{,-efi} b/c of the files moving Reproducible: Steps to Reproduce:
Blocks: (none) => 416
I think -common is more meaningful. So that would be: grub2 requiring grub2-common grub2-efi requiring grub2-common The conflict we currently have between grub2 and grub2-efi would then not be needed, although I have not yet considered the implications of having both installed together. Is the above what you have in mind?
Using -tools would reduce difference with FC though. About conflicts, we could add explicit conflict tags to prevent both to be installed. As the binaries are identical, I guess grub-install looks for either /usr/lib/grub/foobar either though glob() or depending on platform && whether UEFI is enabled or not?
(In reply to Thierry Vignaud from comment #2) > Using -tools would reduce difference with FC though. OK > About conflicts, we could add explicit conflict tags to prevent both to be > installed. > As the binaries are identical, I guess grub-install looks for either > /usr/lib/grub/foobar either though glob() or depending on platform && > whether UEFI is enabled or not? Yes - this I'm not certain about, which is why for safety I kept both packages totally separate in the past. I will build test packages initially without the conflict between grub2 and grub2 -efi to see what happens when both are installed together. I did wonder about just adding the uefi stuff to the grub2 package, but then the unused stuff would just be bloat.
OK I have built and tested the split package in both legacy and UEFI systems with no regressions that I can find. I have kept the conflicts between grub2 and grub2-efi because of the problems that the respective %posts could do on install of the second package - having thought a little more. Do you want this committed or shall I wait for Mga6 Cauldron to open. During testing I accepted rpmnew and noticed that I lost failsafe from/etc/default/grub. I know that you said this would be handled by drak* but I still feel that we should have GRUB_DISABLE_RECOVERY=false in the default in the package.
Created attachment 6526 [details] split spec
Created attachment 6527 [details] split spec - without a couple of typos ;)
Attachment 6526 is obsolete: 0 => 1
As stated in summary, this'll wait mga6 :-)
(In reply to Barry Jackson from comment #4) > Do you want this committed or shall I wait for Mga6 Cauldron to open. we wait for mga6 Cauldron to open > During testing I accepted rpmnew and noticed that I lost failsafe > from/etc/default/grub. On next drakboot run or on next kernel update, it'll be re-added (see below) > I know that you said this would be handled by drak* but I still feel that we > should have GRUB_DISABLE_RECOVERY=false in the default in the package. Whatever is the default, we don't care as drakboot will add it :-) : http://gitweb.mageia.org/software/drakx/tree/perl-install/bootloader.pm#n1798
(In reply to Thierry Vignaud from comment #8) > Whatever is the default, we don't care as drakboot will add it :-) : > http://gitweb.mageia.org/software/drakx/tree/perl-install/bootloader.pm#n1798 Some users who decide to set it true (like me) will not be too happy about a kernel update setting it back to false again. FWIW I still think this should have been set by grub2 in /etc/default/grub on grub2 install (to false) and then left to the user to edit at will. IMHO it's not correct to hard code and overwrite a config like this. I appreciate that only new installs would have had the failsafe entries and not upgraded systems, but anyone wanting it could have easily added it.
Target Milestone: --- => Mageia 6
Fixed in Cauldron (Mga6)
Status: NEW => RESOLVEDResolution: (none) => FIXED