https://bugzilla.redhat.com/show_bug.cgi?id=1481630
--- Comment #43 from Hans de Goede <hdegoede(a)redhat.com> ---
(In reply to Nicolas Chauvet (kwizart) from comment #41)
* Keep from using requires on kernel from userspace. Most of the time
this
is invalid (you could be within a chroot , container or systemd-nspawn,
etc).
Where one would pretty much never install VirtualBox-guest-additions...
Also you need to select the appropriate variant (on x86_64
kernel-debug exists or even kernel-rt).
# FIXME once kernel modules have landed
#Requires: kernel >= 4.FIXME
Ok, so I'm thinking to make the upgrade path issues easier to only
add the VirtualBox-guest-additions to Fedora's repos for F28+ in which case we
can simply assume the kernel-bits will be there and not have this. How does
this sound from an rpmfusion pov, this should make things easy for rpmfusion
too, simply disable the VirtualBox-guest-additions subpackage for F28+.
* The replacement of the RPM Fusion package should works for the
"userspace"
but not much for the kmod-VirtualBox. Best is probably to keep a (virtual)
Provides: VirtualBox-kmod-common = 5.2.2 (the last version of the rpmfusion
counterpart before it is disabled). So that kmod-Virtualbox is kept while it
will not try to seek the main VirtualBox(host) capability.
Then, it will only be a matter for the kernel
So what you're suggesting is that people who upgrade a virtual-machine with the
rpmfusion akmod installed, keep the akmod, but now it will only built (unused)
vbox host modules, instead of building both host _ guest modules, correct?
That sounds reasonable, this should also be easy (change the akmod to only
build host modules) if we make the switch for F28+ and keep older releases as
is.
Note I will try to fix your other remarks my next version.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component