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). > Is this something that can be detected from e.g. maintainer scripts, to show some kind of hint to the affected user?
> 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, to nudge apt into updating that to the backport too? Or is that more likely to get wireless-regdb removed than anything else? Cheers, Julien
