On Thu, Sep 12, 2019 at 01:30:39AM -0400, Daniel Kahn Gillmor wrote:
> [ 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.
Recommends do hold back packages.
>
> > 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.
The closest you get is
wireguard-modules Breaks linux-image-amd64 (>> ${linuxLatestVersion})
or Depends: linux-image-amd64 (= ${linuxLatestVersion}) - it should not matter
all that much I guess. Depends might be nicer.
to be semantically correct, you'd want to have wireguard-modules provide some
linux-modules (= ${linuxLatestVersion}) and have linux-image-amd64
Break that, but ugh.
and then rebuilding the package whenever linux-latest is updated. You'd probably
want to have a linux-modules-extra package or something that builds the meta packages
and versioned packages for OOT modules, using their dkms packages.
wireguard-modules (in l-m-e) Depends wireguard-modules-$kernel (in l-m-e)
wireguard-modules-$kernel (in l-m-e) Built-Using wireguard-dkms
Alternatively, multiple external modules could be grouped together, and
then shipped in a combined package, which likely makes more sense.
Alternative choices are
1) an APT hook that runs at install.pre-prompt and checks whether you'd break external
modules and if so, refuses the install. This should work sort of nicely,
you should speak JSON-RPC over socket.
https://salsa.debian.org/apt-team/apt/blob/master/doc/json-hooks-protocol.md
Only helps actual apt tools though, not any other frontends.
There's also DPkg::Pre-Install-Pkgs which works for everything - that gets a list
of .deb paths on stdin. You'd then check if one of that is a kernel image, and there
are no matching modules, and then show an error message with debconf and exit 1.
2) adding dependency injection code into apt for kernel module packages. It feels a bit
nasty.
FWIW, I don't think the APT & DKMS team lists are the correct place
to discuss this, handling pre-built external kernel modules should be
a broader discussion, at least with the kernel team. There's also the
part where you'd want these kernel modules signed for secure boot /
lock down, so people can install them on secure boot machines.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Attachment:
signature.asc
Description: PGP signature