On Wed, 11 Mar 2020 01:05:49 -0400 Daniel Kahn Gillmor <dkg@debian.org> wrote: > On Wed 2020-03-11 03:50:00 +0000, Ben Hutchings wrote: > > If some of the packages providing a virtual package are explicitly > > installed, and some auto-installed, it could reasonably auto-remove the > > latter group (though I don't think it does). But if all of them are > > auto-installed, which will be the case for kernel packages, it can't > > tell which should be kept and which removed. > > hm, right, i can see how that would be a problem. thanks for the > explanation. > > > But nothing will auto-remove the wireguard package. So you would have > > to keep it as a transitional package for one release cycle, even when > > it depends on just wireguard-tools. > > I don't think it would be a problem to have a transitional package for > one release cycle. do you? No, that's not a problem. > > Yes, this is annoyingly complicated. That's why I need there to be a > > plan. > > I'm open to any suggestions that you think would work better than what > we've talked about so far. Let me know what you prefer. I would have preferred you to do the work, but OK. I think this plan works: 1. We add "Provides: wireguard-modules" to the kernel meta-packages (MR 232). 2. You make the wireguard meta-package depend on wireguard-modules | wireguard-dkms (or the other way around). 3. Wait for bullseye release. Now you can assume the kernel has been upgraded. 4. You turn the wireguard meta-package into a transitional package depending only on wireguard-tools. 5. Wait for bookworm release. Now we can assume the meta-package has been upgraded. 6. We drop "Provides: wireguard-modules". (We could also replace the Provides with a versioned Breaks after step 4, but that doesn't allow us to get to the end state any earlier.) Ben. -- Ben Hutchings 73.46% of all statistics are made up.
Attachment:
signature.asc
Description: This is a digitally signed message part