Hi Andy, On Mon, Aug 3, 2020 at 11:18 PM Andy Whitcroft <[email protected]> wrote: > Yes, this is primarily a bug in the Depends on the wireguard package: > > Depends: wireguard-modules (>= 0.0.20191219) | wireguard-dkms (>= > 0.0.20200121-2), wireguard-tools (>= 1.0.20200513-1)
As discussed, this ordering here has the effect of making manifest the bug you mentioned below, the missing Provides of your meta package. Without this ordering, there would still be a bug, but most users wouldn't notice and things would just be subtly worse and eventually break during some dkms crossover update situation, as we've had before. So, also not good. Not as dramatic, of course, but not good either, and would probably be harder to diagnose and fix later on. And anyway, I'm grateful that we were able to catch this bug so quickly here. So, fixing that Provides:, as you indicated below, remains priority in my mind. For changing the order of the Depends:, I'd encourage you to send a MR to https://salsa.debian.org/debian/wireguard/-/merge_requests or file a Debian bug report, so that the Debian maintainers (CC'd) can deliberate with you on if changing the order actually makes good sense for both Ubuntu and for Debian. In that lucky scenario, Ubuntu can carry on auto importing the changed Debian package, without the need for you to manually change it. > The linux-oem kernel has (separatly) a bug in its Provides so it does > not think it contains wireguard.ko. In that scenario we want the apt > resolver to pick wireguard-dkms as at least that way you have a > wireguard.ko. But the way it is formed it will pick wireguard-modules > for installation if neither is installed already. This can only be > solved by installing an unrelated kernel. Correct. This is the bug to be solved here and now. > Am working on solving these problems variously. Thanks a lot for jumping on this so quickly. I really appreciate it. Regards, Jason
