After pacman -Syu has finished, user is expected to check pacman output anyway,
so will notice their initramfs hasn't been updated and they need to manually correct things before rebooting.
Yup, that's how I expect things to roll on any distribution, even if they do automate the process.
]]>brain0 wrote:"Naturally"? Using mkinitcpio to rebuild kernel modules is not natural in any way.
Using KMS makes it not so absurd as the updated module needs to be included for early start.
I agree with brain0 this is not what mkinitcpio was created for.
Maybe mkinitcpio could check if modules to be included in initramfs are build for the kernel version in the initramfs ?
it could then stop the creation of initramfs with a warning if the right module is not present.
After pacman -Syu has finished, user is expected to check pacman output anyway,
so will notice their initramfs hasn't been updated and they need to manually correct things before rebooting.
Edit :
If a user does reboot with an initramfs that doesn't match installed kernel, they may have some problems but the system will still boot.
]]>"Naturally"? Using mkinitcpio to rebuild kernel modules is not natural in any way.
Using KMS makes it not so absurd as the updated module needs to be included for early start.
]]>Hooks hasn't been implemented yet, but in the case of modules for dkms and fglrx, one plan would be to use a hook to wait until after linux-headers and the affected packages are updated/installed before building the required modules (probably the easiest way to do it).
Sounds good. So for when are the hooks?
]]>artiom wrote:After a kernel upgrade you need to rebuild DMKS modules and it is naturally could be done with a mkninicpio hook.
"Naturally"? Using mkinitcpio to rebuild kernel modules is not natural in any way. It is abuse of the tool for a purpose it was never meant for. I will not add entirely incorrect dependencies to add official support for this brokenness.
Agreed. This will never be a supported use case for mkinitcpio.
]]>After a kernel upgrade you need to rebuild DMKS modules and it is naturally could be done with a mkninicpio hook.
"Naturally"? Using mkinitcpio to rebuild kernel modules is not natural in any way. It is abuse of the tool for a purpose it was never meant for. I will not add entirely incorrect dependencies to add official support for this brokenness.
]]>So if I understood well, the dkms package should install a hook which will require headers install/upgrade in case of kernel upgrade. Is "Requires" option is suitable for it?
Hooks hasn't been implemented yet, but in the case of modules for dkms and fglrx, one plan would be to use a hook to wait until after linux-headers and the affected packages are updated/installed before building the required modules (probably the easiest way to do it).
]]>It has, but when this package is not updated, but kernel is updated headers will be updated after the kernel package. This breakes the mkinitcpio hook which recompile the modules on kernel upgrade.
You are right, i failed to understand this was the problem. By the way here is the wikipage for the hooks clfarron is talking about.
]]>1. The packages that make use of dkms to rebuild modules should have a dependency on the linux-headers package.
It has, but when this package is not updated, but kernel is updated headers will be updated after the kernel package. This breakes the mkinitcpio hook which recompile the modules on kernel upgrade.
]]>EDIT:
Even worse if I want to pull only kernel upgrade headers will not be upgraded at all.
Partial upgrades are not supported.
]]>EDIT: I maintain kernels in the AUR, and I personally prefer to have separate linux and headers packages.
]]>Headers package is really small and the majority of users won't ever notice if it will be installed with an upgrade. Gnome or KDE bring much more useless packages as hard dependencies.
That's how they are packaged upstream, and so that's how it's done here.
I'll float another idea past, just because I've seen it: @shivik has completely done away with a separate headers package for linux-lqx and included them in the main package when you build it.
]]>