On Sun, 2020-04-26 at 16:48 +0200, Julien Cristau wrote: > On Fri, Jan 31, 2020 at 02:26:18PM +0100, Ben Hutchings wrote: > > I failed to update wireless-regdb for some time, as it needed some > > significant work to prepare for the regulatory database being directly > > loaded by the kernel (instead of by crda). This was introduced in > > Linux 4.15, but is currently disabled in all Debian suites. It will > > be enabled starting with 5.5. > > > > The version now in unstable has: > > > > 1. regulatory.bin: loadable by crda, trusted by Debian crda > > 2. regulatory.db-debian, regulatory.db.p7s-debian: > > loadable by kernel, trusted by future Debian kernels > > 3. regulatory.db-upstream, regulatory.db.p7s-upstream: > > loadable by kernel, trusted by upstream and future Debian kernels > > 4. regulatory.db, regulatory.db.p7s: alternative links for either > > (2) or (3) > > > > So this should be backward-compatible with all supported Debian > > releases, with one exception: > > > > On a system that has a recent kernel and (3) from elsewhere, *and* > > also a currently unused wireless-regdb package, upgrading > > wireless-regdb will effectively replace (3) with (2), which is not > > trusted by their kernel. They will need to run update-alternatives to > > fix this (this is documented in README.Debian).
I didn't actually test this, but I have now. In fact, update- alternatives will *not* replace /lib/firmware/regulatory.db but will issue warnings. Package installation still succeeds. > Is this something that can be detected from e.g. maintainer scripts, to > show some kind of hint to the affected user? I think that the current upgrade behaviour is safe. However I should probably implement replacement with the "upstream" alternative in case regulatory.db is already present. > > The update for (1) definitely should be delivered to all suites, but > > I'm undecided whether the other files should be included. Please > > advise what I should do. > > > I guess our options for stable are: > a. ship 1/2/3/4 in a point release > b. ship an update for 1 in a point release, ship 1/2/3/4 in backports > > For option b, can we reasonably have the backports kernel Break old > wireless-regdb, It already does, in the version that's in backports-NEW. > to nudge apt into updating that to the backport too? Or > is that more likely to get wireless-regdb removed than anything else? I don't know. I have updated wireless-regdb in buster-backports, so the recommended "apt install -t buster-backports linux-image-amd64" will work. But upgrades might not. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it.
signature.asc
Description: This is a digitally signed message part
