You are not logged in.
Even if it is not technically dependent packages there is a functional dependency. Which became technical when you use DKMS for example.
After a kernel upgrade you need to rebuild DMKS modules and it is naturally could be done with a mkninicpio hook. However this will fail because headers are upgraded after kernel. Even worse if I want to pull only kernel upgrade headers will not be upgraded at all.
Offline
Personally, I believe that linux-headers shouldn't be a hard dependency of the linux package, purely because there are people that don't need the linux-headers (so some would argue it's clutter). Yes, it'd be nice to make it a dependency for those of us that need to build modules, so it gets installed first, but my previous point
Also, the concept of Pacman Hooks is still in the works, which might make the point of having to rebuild modules yourself after kernel upgrades moot. Just see what Vi0L0's done with the catalyst-hook package.
And before you ask, Allan has repeatedly told me that the "SyncFirst" option is never coming back.
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
I am not sure about what you mean with "Packman Hook". I found a systemd service to rebuild module on shutdown but this is not perfect solution. In case of KMS with early start it can cause an unbootable sytem.
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.
Offline
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.
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
That's a good idea too. Linux way of doing things includes to compile it from sources, so headers could be integrated no only with kernel but with libraries too.
What is the best way to give this idea to devs?
Offline
ArchLinux Mailing List is probably where you want to start this discussion. It could go on the Bug Tracker as a Feature Request against the linux package, but I think Mailing List is better.
EDIT: I maintain kernels in the AUR, and I personally prefer to have separate linux and headers packages.
Last edited by clfarron4 (2014-04-29 12:09:06)
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
1. The packages that make use of dkms to rebuild modules should have a dependency on the linux-headers package.
2. The linux-headers package is already an optional dependency of the dkms package.
3. Nothing stops you from installing the package manually.
EDIT:
Even worse if I want to pull only kernel upgrade headers will not be upgraded at all.
Partial upgrades are not supported.
Last edited by teateawhy (2014-04-29 13:59:05)
Offline
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.
Offline
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.
Offline
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?
Offline
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).
Last edited by clfarron4 (2014-04-29 15:52:14)
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
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.
Offline
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.
Offline
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?
Offline
"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.
Offline
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.
Last edited by Lone_Wolf (2014-04-30 12:42:39)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
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.
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline