[ changing out dkms-maint@lists.alioth.debian.org for
dkms@packages.debian.org since the former mailing list didn't survive
the alioth migration ]
On Wed 2019-09-11 16:11:37 -0400, Jason A. Donenfeld wrote:
> 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.
fwiw, jason's references below to "postinst.d" is (i think)
/etc/kernel/postinst.d/ , and "module-packages" is a placeholder for
(for example) "wireguard-module-4.19.0-5-amd64".
I'll describe why i think the various proposals are unsatisfactory
below, in the hopes that we can use those insights to converge on
something that is more satisfactory.
> Proposal A) Hack up grub/elilo/uboot scripts.
If we could get this to work as described, this looks to me like it
would be likely to be pretty confusing.
I'm imagining an admin saying "wtf, how come my reboot isn't booting
into the new kernel?" -- it's a pretty subtle change in behavior, and i
could imagine this change causing people to run an
old/outdated/vulnerable kernel by accident longer than they meant to,
b/c the usual workflow of "upgrade, reboot" is no longer guaranteed to
boot into the newer kernel. The admin now has to manually check the
kernel they've rebooted into.
I mean, they *should* do that check anyway, but it seems unwise to just
silently keep them on the old kernel if the rest of the package
management state looks like the new kernel is installed. it seems to
violate the principle of least surprise.
> Proposal B) Drop something nasty into postinst.d.
This is unsatisfactory because it leaves the system in an unclean state,
with at least the new kernel package unpacked but not configured.
Depending on the state of the rest of the system, this unclean state
might also cause other problems (other packages might not want to
configure themselves because this package isn't itself configured
properly, etc).
> Proposal C) Drop something with a <blink> tag into postinst.d.
As much as i like supersonic dog alerts, i worry that this kind of thing
will just be missed by an inattentive administrator.
> Proposal D) Inject a hard reverse dependency into kernel packages.
i don't know how to do this, but…
> Kernel packages would fail to install if the installed module-packages
> aren't available for their version numbers.
i think proposal (B) is the closest to what you've described in the
sentences here -- the kernel package can be unpacked, but fail to be
configured, which means that its installation will fail (though the
package will be in the sort of unsatisfactory half-way state described
above).
But the summary is (i think) asking for something different than (B): I
think what we really want is for apt to refuse to even *try* to install
the new package -- so that it's clear that a new kernel package is
available, but both dpkg and apt will refuse to install it due to a
missing dependency.
> 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.
i'm not sure what you expect "offered for install" to mean, but i think
in most debian systems, an available upgrade that has all of its hard
dependencies ("Depends:") met *will* be offered for installation by "apt
upgrade", even if its soft dependencies ("Recommends:") cannot be met.
I hope the apt developers can correct me if i'm wrong.
> 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."
I agree that the cleanest form of (D) (not its "B"-like interpretation)
is the ideal situation, but i also don't know how to express it cleanly.
--dkg
Attachment:
signature.asc
Description: PGP signature