Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#30028 - [linux] - addition to linux.install to call dkms if on the target system

Attached to Project: Arch Linux
Opened by John (graysky) - Saturday, 26 May 2012, 15:49 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 09 June 2012, 08:03 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas B├Ąchler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No


Description: Attached patch should allow for auto calling of dkms on kernel update if user has dkms installed. I do not believe the issues raise in the following are relevant to this request:

(Patch by naveen).
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Saturday, 09 June 2012, 08:03 GMT
Reason for closing:  Won't implement
Comment by John (graysky) - Saturday, 26 May 2012, 15:49 GMT
Forgot to change the category to Package: Core.
Comment by Dave Reisner (falconindy) - Saturday, 26 May 2012, 15:52 GMT
It's completely broken to call pacman itself from an install hook, even for a local DB query.
Comment by John (graysky) - Saturday, 26 May 2012, 16:52 GMT
@Dave - can you elaborate a bit? I see other lines in linux.install that do just this. For example in the post_upgrade function.
Comment by Dave Reisner (falconindy) - Saturday, 26 May 2012, 16:59 GMT
pacman might not even work in the middle of an upgrade. We statically compile vercmp against libalpm explicitly to avoid this sort of thing. The sort of cautionary messages that pacman is used to generate is crap for other reasons (why no syslinux, or burg, or <insert other bootloader>).

The name of the dkms package might change, or there could be some other provider (dkms-git?). You're about to call a binary called dkms, so check for a binary available called dkms.

if type -p dkms >/dev/null; then
dkms -k autoinstall $KERNEL_VERSION

That said, I don't think this crap has any place in an install scriptlet.
Comment by John (graysky) - Saturday, 26 May 2012, 18:02 GMT
@Dave - thanks for the clarification. If not in an install scriptlet, where do you feel it would be appropriate?
Comment by John (graysky) - Sunday, 27 May 2012, 12:35 GMT
Updated patch per Dave's suggestion.
Comment by Tobias Powalowski (tpowa) - Sunday, 27 May 2012, 15:13 GMT
I don't like adding stuff to .install file. Thomas your opinion on this?
We don't check on mounted boot nor do we run lilo out of there.
Comment by naveen (naveen) - Sunday, 27 May 2012, 16:24 GMT
@Dave: Thanks for the suggestions. I can see calling pacman within a .install to be problematic, but my patch was based on the fact that the existing .install calls pacman.

@John: thanks for the feature request and for updating the patch. I felt a further change to ignore errors from dkms would make this more robust. Just to ensure the kernel install never fails due to this. I've attached an updated patch.
Comment by naveen (naveen) - Friday, 08 June 2012, 15:59 GMT
Bump. Can you kindly include this? I have tested this and it works fine for me (including a scenario where dkms build failed, but the kernel install wasn't affected).
In my opinion, this patch puts dkms to its proper use.
Comment by Tobias Powalowski (tpowa) - Friday, 08 June 2012, 17:18 GMT
I will not add this. The install file should be as clean as possible.
Comment by Tobias Powalowski (tpowa) - Saturday, 09 June 2012, 08:02 GMT
Thomas said pacman should implement this and not the kernel.install file.
Closing as won't implement please open a new task against pacman.