Not sure. Probably just ignored.
Yes. Try out.
That’s why all changes go through developers → testers → stable-proposed-updates → stable repository.
The problem here is, we cannot predict the future. If backport kernels will break VirtualBox guest additions.
Major things coming to mind:
- Fixed screen resolution (too big, too small, scrolling, not using full window space, black border).
- No shared folders.
- No copy/paste from inside/outside VM.
- Trapping of keyboard/mice inside VM until VirtualBox host key is pressed.
more details here perhaps:
The lesser evil. A packaging hack is the path of least resistance IMO.
Or if we are enabling backports, then simply omit setting this apt config in VBox builds to begin with while designating the stable kernel during the build process?
Enabling backports is inappropriate for a distribution.
Enabling backports alone does nothing. Still required APT pinning, which again is inappropriate for a distribution.
- If not using virtualizer specific kernel versions: Would have to download the package from Debian backports and upload to Whonix stable.
- If using virtualizer specific kernel versions: Would require some packaging hack. Perhaps require to recompile the kernel.
I don’t like the idea of virtualizer specific kernel versions. That’s adding a lot complexity. Hard to develop / test since involving different tests on different virtualizers.
It would also only be effective for a platform that I don’t maintain, KVM.
(Qubes is not yet Qubes VM kernel by default.)
Debian bug linux-image-amd64 vs linux-headers-amd64 Debian buster-backports version mismatch bpo.2 vs bpo.3 shows that just enabling backports repository might lead to issues. In this example, breaking all kernel modules due to kernel image vs kernel headers version mismatch from backports packages.debian.org.
OK. That’s a good citation for the wiki on why we don’t enable backports.