Cannot install wireguard-tools on systems without .deb kernel - Drop useless depends on wireguard-modules / wireguard-dkms

This bug was fixed in the package wireguard - 1.0.20210914-1ubuntu3

---------------
wireguard (1.0.20210914-1ubuntu3) lunar; urgency=medium

  * Drop depends on wireguard-modules (always built-in), wireguard-dkms
    (removed from the archive). This makes wireguard package sort of
    redundant. LP: #2008086
  * Drop 0002-Avoid-requiring-glibc-2.25-for-wireguard-tools.patch as
    glibc-2.25 has been around since forever.
  * Cherry-pick upstream fixups from master.

 -- Dimitri John Ledkov <email address hidden> Wed, 22 Feb 2023 12:35:51 +0000

What is broken with wireguard that justifies an SRU? There is no wireguard-modules package in either release, this is a virtual package provided by all of the kernels. This looks like needless churn of the wireguard package to me.

An upload of wireguard to kinetic-proposed has been rejected from the upload queue for the following reason: "No response from submitter to request for justification".

@vorlon

1) a container or chroot running on jammy or kinetic host, cannot install wireguard userspace tooling and use it, without needlesly installing an unused kernel package.

2) On Ubuntu Desktop (as shipped for the xinyi/desktop-fde project) with kernel provided by a snap, there is nothing in deb userspace that allows to install something that provies "wireguard-modules", meaning it is not possible to use wireguard.

@racb

Please do not edit bug description without consultation.

> * There likely exist users who use their own kernel builds. They may not match ours. If they have automation that just installs "wireguard" and that works today, this change would break that automation.

That assessment is incorrect. If self-built kernel doesn't provide wireguard.ko, no dependencies will create it (i.e. there is no dkms package that would compile wireguard.ko). Instead, currently a useless copy of ubuntu kernel will be demanded to be installed to satisfy the virtual provides. Or the userspace package will not be installed at all. Meaning "just installing `wireguard` on a kernel that chose not to copile wireguard.ko, does not result in a working wireguard today with or without this change.

I am removing your addition, which is factually incorrect.

In jammy there still is dkms module, which is severely out of date, compared to the supported kernels and the wireguard they ship:

 wireguard-dkms | 1.0.20210606-1 | jammy/universe | all

Also note https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1873288 request to not recommend wireguard-dkms in jammy

> [ Impact ]

> * wireguard package has historic depends on wireguard-modules | wireguard-dkms, which are now useless. Wireguard module has been built-in since forever, and wireguard-dkms has been removed from the archive. Drop these as no longer required.

This doesn't describe how users of stable releases are impacted, which is necessary to consider if an SRU is appropriate. It's a true statement but not really part of any user impact as far as I can tell?

> * This can be safely dropped in jammy sru as well, to allow wireguard-tools userspace package to be installable with hwe kernels from lunar, and inside containers.

How does this impact users, though? What scenarios exist where users are trying to install wireguard-tools inside containers? Why can't you just provide the wireguard-modules Provides in your HWE backports from Lunar?

> 2) On Ubuntu Desktop (as shipped for the xinyi/desktop-fde project) with kernel provided by a snap, there is nothing in deb userspace that allows to install something that provies "wireguard-modules", meaning it is not possible to use wireguard.

Why can that project not provide an equivs-style deb that Provides: wireguard-modules in scenarios where it is ensuring that such a kernel is available? Wouldn't this reduce risk to existing users of Jammy?

Marking as Incomplete for the benefit of SRU reviewers. Please set back once my questions are answered.

An upload of wireguard to jammy-proposed has been rejected from the upload queue for the following reason: "Question in https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/2008086 outstanding for more than a month".