On 11/11/19 12:00 PM, Damjan Georgievski via arch-general wrote:

...

This has been discussed a bit on the dracut thread, as well on some other threads over time. I *personally* don't like the complexity of kernel-install that much.

I've now read this twice on Arch mail lists, so I have to ask, without any presumptions on my side, what are the arguments against kernel-install?

I must say, I don't see much complexity in it. It's only a 184 line bash script[1].

A one line bash command in the PKGBUILD is 184x less complex, then. That's a pretty major difference. (One line of bash in the PKGBUILD, plus running mkinitcpio -p linux, vs. kernel-install plus still running mkinitcpio -k "${uname_r}" -g /boot/$MACHINE_ID/${uname_r}/initrd -- mkinitcpio is a static constant here, unless you switch to dracut.) But if you want my $0.02 why I personally think it is too complex, the answer is I've read the script and internalized what it does, and irrespective of the "line count" I consider the actions which it undertakes to do, to be too many complex moving parts to make me comfortable relying on it on my own laptop.

And as added feature, it decouples the kernel install from the kernel package install (and pacman), also defines couple of easy-to-use config locations like /etc/kernel/cmdline

But I guess I might be missing something.

For a really simple setup, it is totally unnecessary and I would prefer my kernel to be tracked by pacman. It needs no modifications in order for me to use it in my bootloader (I use grub, which is capable of booting with a 3-line grub.cfg, 4 lines if your kernel is stored on a luks-encrypted partition), so why not simply use it from pacman's own installation location? Why is it explicitly a feature to "decouple the kernel from the package"? Why is it a feature to store the kernel cmdline in a location divorced from your bootloader? That being said, there is literally nothing whatsoever stopping people from using kernel-install if they want to. Aside: kernel-install surely does not care whether it uses the 'cp' command to copy files from /boot, or whether it uses the 'cp' command to copy them from /lib/modules. So it was fully usable 5 years ago, as far as I can tell. It was even fully usable during the short transition period when /lib/modules/${uname_r}/vmlinuz was a symbolic link pointing to /boot/vmlinuz-linux, because the POSIX definition of 'cp' mandates that it copy over the file contents of the regular file which the symbolic link points to (unless the script overrides this by using the -P, --no-dereference option). It works and worked with dracut too, since dracut's uefi executable generation also reads file contents after doing symlink traversal, via objcopy. The entire history of Arch Linux has been completely one hundred percent supportive of people's desire to use kernel-install. If no one is doing it, I can only presume no one actually wanted to do it. ... Now, if the discussion is about making the kernel-install workflow a hard requirement of using mkinitcpio, I do not understand the logic here. mkinitcpio is one of the programs executed by kernel-install, as implemented via /usr/lib/kernel/install.d/50-mkinitcpio.install As such, it would make zero sense for mkinitcpio's own alpm-hook to execute kernel-install before running mkinitcpio, only for kernel-install to then run mkinitcpio again, in addition to a bunch of other kernel-install specific stuff that isn't mkinitcpio's responsibility. kernel-install is NOT a program to copy over the kernel to the bootloader's final destination! It is a one-stop-shop that wants to do everything from beginning to end, including take charge of mkinitcpio itself. If you want to use kernel-install, then delete and mask the alpm-hooks /usr/share/libalpm/hooks/60-mkinitcpio-remove.hook /usr/share/libalpm/hooks/90-mkinitcpio-install.hook and write your own, which trigger on the same package updates but instead run kernel-install according to the documented kernel-install API. Also, please write wiki documentation for it. As far as I can tell, no Arch Linux user has ever gone to the effort of writing up guidance on using the officially supported kernel-install program which Arch Linux has always installed and has provided mkinitcpio plugins for since September 2013. It would be wonderful if Arch Linux would, in the spirit of user choice to which we aspire, provide guidance on opting into the use of a technology that a significant percentage of our active community says they would like to use. -- Eli Schwartz Bug Wrangler and Trusted User