On Tue, Mar 10, 2020 at 8:52 PM Ben Hutchings <b...@decadent.org.uk> wrote: > > On Tue, 2020-03-10 at 17:02 -0600, Jason A. Donenfeld wrote: > > Please coordinate with me for doing this. Actually, if this sounds > > interesting to you, I'll backport it myself, along with the missing > > crypto/ bits, and send you a git bundle of patches for 5.5. > > > > In other words, just say "yes please", and I'll supply the rest. > > Either a git bundle or quilt patch series is fine.
Voila: https://data.zx2c4.com/wireguard-5.5.8-20a586ec4f5acf195f71caea55c5a33c574078cb69712da591467ffc08dd8b72.zip That will apply on top of 5.5.8. Let me know if you have any problems, and please poke me after this is done so I can test it out. > > > Then you can apply this to your tree and add the Provides as dkg > > asked. > > We definitely can't add a Provides on "real" kernel packages, because > this breaks auto-removal of old packages. We could possibly add it to > the meta-packages, but there would have to be a plan for how we can > drop it later (and have the Wireguard user-space just assume the kernel > supports it). We definitely shouldn't accumulate Provides for every > component that was previously packaged out-of-tree. There are tricky Debian concerns here I don't totally grok, but what I'd like to happen is: - A user is on stock Debian and runs `apt install wireguard`: only wireguard-tools is pulled in. - A user is on weird Debian (say, some AWS kernel) and runs `apt install wireguard`: wireguard-tools and wireguard-dkms are pulled in. I was under the impression that the "Provides" mechanism does a good job at that. But perhaps there's another good way you have in mind.