I've reviewed the logic and yes you are correct it will build for the
currently booted kernel as well as the newest kernel. I do feel that
both of those scenarios should yield operational modules though, and if
not, the user should know they failed.
Look at it this way. If the user is booting an older kernel but has a newer
one installed, one of two scenarios is happening:
1) They have a problem with the newer kernel on their system and knowingly
chose an older one
2) They've upgraded to a newer one that they don't yet know works because they
haven't rebooted, and may need to revert to this older one that works
In both of those scenarios they should expect that the kernel module
works with both of the kernels. If their newer kernel fails, then
they'll need to boot back into the old one and may need the module
there.
A corollary to the above is the situation of a dist-upgrade from say N
to O. They'll be jumping from 2.6.38 to 3.0.0 kernels. Lets say they
had fglrx installed before the upgrade and intend to use it after the
upgrade. The module henceforth needs to build on 2.6.38 as well as
3.0.0. It will be built on 2.6.38 from the fglrx postinstall /dkms
common postinstall (which detects the upgrade flag) and then built on
3.0.0 from the kernel postinstall.
If for some reason they can't boot 3.0.0 on their hardware, they'll need
to revert back to 2.6.38 to investigate, meaning they'll still need the
fglrx module there to boot the system.
** Changed in: dkms (Ubuntu)
Status: Confirmed => Opinion
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802617
Title:
module build error fails package installations
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/802617/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
