You are not logged in.

#1 2014-04-29 08:34:04

artiom
Member
From: France
Registered: 2008-07-29
Posts: 111

DKMS issue (linux-headers should be in dependecies for kernel)

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

#2 2014-04-29 08:46:01

clfarron4
Member
From: London, UK
Registered: 2013-06-28
Posts: 2,163
Website

Re: DKMS issue (linux-headers should be in dependecies for kernel)

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

#3 2014-04-29 08:58:54

artiom
Member
From: France
Registered: 2008-07-29
Posts: 111

Re: DKMS issue (linux-headers should be in dependecies for kernel)

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

#4 2014-04-29 11:34:36

clfarron4
Member
From: London, UK
Registered: 2013-06-28
Posts: 2,163
Website

Re: DKMS issue (linux-headers should be in dependecies for kernel)

artiom wrote:

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

#5 2014-04-29 12:04:07

artiom
Member
From: France
Registered: 2008-07-29
Posts: 111

Re: DKMS issue (linux-headers should be in dependecies for kernel)

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

#6 2014-04-29 12:08:22

clfarron4
Member
From: London, UK
Registered: 2013-06-28
Posts: 2,163
Website

Re: DKMS issue (linux-headers should be in dependecies for kernel)

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

#7 2014-04-29 13:57:05

teateawhy
Member
From: GER
Registered: 2012-03-05
Posts: 1,138
Website

Re: DKMS issue (linux-headers should be in dependecies for kernel)

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

#8 2014-04-29 14:03:52

artiom
Member
From: France
Registered: 2008-07-29
Posts: 111

Re: DKMS issue (linux-headers should be in dependecies for kernel)

teateawhy wrote:

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

#9 2014-04-29 14:34:48

teateawhy
Member
From: GER
Registered: 2012-03-05
Posts: 1,138
Website

Re: DKMS issue (linux-headers should be in dependecies for kernel)

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

#10 2014-04-29 14:51:37

artiom
Member
From: France
Registered: 2008-07-29
Posts: 111

Re: DKMS issue (linux-headers should be in dependecies for kernel)

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

#11 2014-04-29 15:51:39

clfarron4
Member
From: London, UK
Registered: 2013-06-28
Posts: 2,163
Website

Re: DKMS issue (linux-headers should be in dependecies for kernel)

artiom wrote:

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

#12 2014-04-29 19:34:07

brain0
Developer
From: Aachen - Germany
Registered: 2005-01-03
Posts: 1,382

Re: DKMS issue (linux-headers should be in dependecies for kernel)

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.

Offline

#13 2014-04-29 19:40:09

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: DKMS issue (linux-headers should be in dependecies for kernel)

brain0 wrote:
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

#14 2014-04-30 08:25:03

artiom
Member
From: France
Registered: 2008-07-29
Posts: 111

Re: DKMS issue (linux-headers should be in dependecies for kernel)

clfarron4 wrote:

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

#15 2014-04-30 08:27:00

artiom
Member
From: France
Registered: 2008-07-29
Posts: 111

Re: DKMS issue (linux-headers should be in dependecies for kernel)

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.

Offline

#16 2014-04-30 12:41:09

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: DKMS issue (linux-headers should be in dependecies for kernel)

artiom wrote:
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.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#17 2014-04-30 17:59:48

clfarron4
Member
From: London, UK
Registered: 2013-06-28
Posts: 2,163
Website

Re: DKMS issue (linux-headers should be in dependecies for kernel)

Lone_Wolf wrote:

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

Board footer

Powered by FluxBB