https://bugzilla.redhat.com/show_bug.cgi?id=1481630
--- Comment #41 from Nicolas Chauvet (kwizart) <kwizart(a)gmail.com> ---
(In reply to Hans de Goede from comment #38)
Here is a new version of the pkg, updated to 5.2.2:
SPEC:
https://fedorapeople.org/~jwrdegoede/VirtualBox-guest-additions.spec
SRPM:
https://fedorapeople.org/~jwrdegoede/VirtualBox-guest-additions-5.2.2-1.fc27.
src.rpm
Unfortunately the kernel patches are still awaiting review by the misc
subsys maintainers upstream. I did manage to get a review done by another
kernel contributor (and addressed his comments), so hopefully something will
happen wrt this soon.
Quick review with few minors things:
* 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). 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
* Please use pkgconf --libs libpng and etc not to hardcode one particular
library path. (say if there is a need to use one particular scl at some
point).
* Is there a way "not to hardcode the vendor", such as:
VBOX_BUILD_PUBLISHER=_%{?vendor}%{?!vendor:Unknown}
* 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
Obsoletes/Provides for the akmod isn't an option because it will affect host
kmod-VirtualBox and VirtualBox users.
Another option is probably to only have the Obsoletes: akmod-VirtualBox <
5.22-100
(needs testing).
--
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