-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
common.postinst and AUTOINSTALL="" #368
Comments
I'll test the following in
|
The current code skips the module if
As mentioned previously I would love us to nuke Can I offer some virtual 🍪 to sketch and test how it works from Debian POV? Thanks in advance |
dkms_common.postinst and kernel_postinst.d_dkms.in are two orthogonal things: if dkms_common.postinst is not used elsewhere I have no problem moving it to the debian packaging, but we cannot get rid of it for a few years at least since it is referenced in the maintainer scripts of all *-dkms packages |
Notable bits:
I would love to see AUTOINSTALL fixed, but IMHO we should looked into at least some of the above first. |
AUTOINSTALL is disabled by default (value is unset/empty) Closes: dell#368
Ideally this common.postinst functionality ("build $module for all kernels") should be part of dkms (so it could reuse the existing logic) and common.postinst simply calls dkms like kernel_postinst.d_dkms calls |
Fully agreed - it seems like others not using Opened a separate task with some details and pointers. Thanks o/ |
If a dkms package does not set
AUTOINSTALL=yes
in its dkms.conf (yes, we have one such package in Debian, but I don't know whether this omission is intentional... ), what should common.postinst do upon installation?Should it really build and install the module?
Right now we have inconsistent behavior depending on the installation order:
case a)
case b)
IMO common.postinst should honor the AUTOINSTALL setting and not try to build and install the module.
The text was updated successfully, but these errors were encountered: