[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: building and distributing binary out-of-tree Linux kernel module packages within debian



Hi folks,

Here are several proposals. I'm hoping somebody can veto some of these
right off the bat and then we can focus our energy on what remains.

Proposal A) Hack up grub/elilo/uboot scripts.

Currently after a kernel or boot-related package is installed, it
calls into some postinst.d scripts to regenerate an initramfs,
regenerate a grub menu, and perhaps other tasks too. After the
installation of a new kernel, the grub scripts would simply ignore it
if of the package-modules installed, at least one is not (yet)
available for that kernel. This way users could upgrade normally, but
they wouldn't accidentally boot into the new kernel until all of its
module packages are ready for it. Since module packages would also
provoke the same postinst.d set of scripts, when the final module
package does become available, the grub selection would get updated as
such.

Proposal B) Drop something nasty into postinst.d.

Some package would be added that module-packages depend on, which
would drop a file into postinst.d. This file would cause post
installation of kernels to fail if the package-modules aren't yet
available, and hence apt would error out, and then the user would
probably aptupdate again until it became available.

Proposal C) Drop something with a <blink> tag into postinst.d.

Some package would be added that module-packages depend on, which
would drop a file into postinst.d. This file would cause post
installation of kernels to emit blinking red text and cause the
soundcard to emit supersonic sound waves to cause all the neighborhood
dogs to go insane, warning not to reboot if the package-modules aren't
yet available,.

Proposal D) Inject a hard reverse dependency into kernel packages.

Kernel packages would fail to install if the installed module-packages
aren't available for their version numbers.

Proposal E) Inject a soft reverse dependency into kernel packages.

Kernel packages wouldn't yet be offered for install until the
installed module-packages are available for their version numbers.


D and E seem the most interesting to me, but they require a piece of
logic, and I have no idea whether apt can express it: "If package
wireguard-modules is installed, for each possible VVV, cause
kernel-image-VVV depend on wireguard-modules-VVV." Or more generally:
"If package PPP-modules is installed, for each possible VVV, cause
kernel-image-VVV depend on PPP-modules-VVV."

Alternatively, if there's an obvious proposal F and G and H, somebody
please pipe up.

Thanks,
Jason


Reply to: