When the split between qemu-kvm and qemu-kvm-core happened, some dependencies ended up staying in qemu-kvm-core while they should actually be move to qemu-kvm or to the modules using them. This has being fixed slowly (see bz#1872853 and bz#1924766), but there are still some left overs. The idea is that qemu-kvm-core should be the lightest as possible. Users installing it directly should be aware of the submodules and dependencies they want. If they don't, they can always installed qemu-kvm instead. This is currently being opened to make a case to move edk2, qemu-img and qemu-kvm-docs to qemu-kvm package but other dependencies might be included later.
Assigned to Jeff for initial triage per bz process and age of bug created or assigned to virt-maint without triage.
QA_ack, please?
QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.
Hi, The description of this BZ is very poor. I'm sorry for that. We did three things in this BZ: We moved the qemu-kvm-docs dependency from qemu-kvm-common to qemu-kvm We fixed some warnings on the build process (I don't think you can verify that) I created a new subpackage called qemu-kvm-hw-usbredir. The creation of this subpackage moves the rw-usb-redirect.so file from qemu-kvm-core to the qemu-kvm-hw-usbredir rpm From your message you're comparing qemu-kvm-core file change, and I can see that the rw-usb-redirect.so disapear from there. So that's good. My suggestion to test this: check if that file is included in qemu-kvm-hw-usbredir. Then see if qemu-kvm-hw-usbredir is *NOT* installed when you install qemu-kvm-core. Then check if the package gets installed when you install qemu-kvm.
(In reply to Danilo Cesar Lemes de Paula from comment #11) > We did three things in this BZ: > > We moved the qemu-kvm-docs dependency from qemu-kvm-common to qemu-kvm > We fixed some warnings on the build process (I don't think you can verify > that) > I created a new subpackage called qemu-kvm-hw-usbredir. > > The creation of this subpackage moves the rw-usb-redirect.so file from > qemu-kvm-core to the qemu-kvm-hw-usbredir rpm I realize that I'm quite late to the party here, but I just noticed that there are differences between the way the QEMU package has been split in Fedora and in RHEL. In particular, usbredir support in Fedora is now part of the qemu-device-usb-redirect subpackage. This name is consistent with the fact that there are several other qemu-device-* subpackages in Fedora. Comparing the most recent build of QEMU 6.0.0 in CentOS Stream 8 and Fedora https://cbs.centos.org/koji/buildinfo?buildID=35303 https://koji.fedoraproject.org/koji/buildinfo?buildID=1811148 it would seem that modularization of the QEMU package is quite a bit further along in Fedora. That's perfectly fine! It takes time for changes to flow all the way to RHEL :) However, if we ignore the obvious difference in prefix ("qemu-" in Fedora vs "qemu-kvm-" in RHEL), all subpackages the same name in both distros *except* for the usbredir one. I think that it's a bad idea to have this inconsistency, and that we should address it before RHEL AV 8.5 hits GA by changing the subpackage name to match Fedora. What do the QEMU maintainers think? Is there perhaps a rationale behind the mismatch that I am not aware of?
(In reply to Andrea Bolognani from comment #13) > However, if we ignore the obvious difference in prefix ("qemu-" in > Fedora vs "qemu-kvm-" in RHEL), all subpackages the same name in both > distros *except* for the usbredir one. There's actually another mismatch: qemu-kvm-ui-spice in RHEL vs qemu-ui-spice-core/qemu-ui-spice-app in Fedora. I have no idea whether the RHEL subpackage matches one of the Fedora ones in contents but not in name, or if it's just a case of the Fedora split being more granular.
Ping? I'm afraid we might be too late to change this for RHEL AV 8.5 already...
Hi Andrea, it actually is. Perhaps we should create a request for this to be fixed in RHEL-9 (or do you still have a case for RHEL-8)? Please consider that this package *never* hit RHEL-8 (only AV) and if you have a justification (I believe you have) we can fix this for 8.6. ping me on IRC or somewhere else tomorrow and we can talk this further.
(In reply to Danilo Cesar Lemes de Paula from comment #16) > Hi Andrea, it actually is. I figured as much :( Unfortunately I noticed this very late. > Perhaps we should create a request for this to be fixed in RHEL-9 (or do you > still have a case for RHEL-8)? > > Please consider that this package *never* hit RHEL-8 (only AV) and if you > have a justification (I believe you have) we can fix this for 8.6. > ping me on IRC or somewhere else tomorrow and we can talk this further. Ideally we would have caught this before shipping it to customers, but fixing it in RHEL 9 and RHEL 8.6 is the next best thing. I thing we should do both. Should I just go ahead and open BZs to track the change?
(In reply to Andrea Bolognani from comment #17) > (In reply to Danilo Cesar Lemes de Paula from comment #16) > > Perhaps we should create a request for this to be fixed in RHEL-9 (or do you > > still have a case for RHEL-8)? > > > > Please consider that this package *never* hit RHEL-8 (only AV) and if you > > have a justification (I believe you have) we can fix this for 8.6. > > ping me on IRC or somewhere else tomorrow and we can talk this further. > > Ideally we would have caught this before shipping it to customers, > but fixing it in RHEL 9 and RHEL 8.6 is the next best thing. I thing > we should do both. > > Should I just go ahead and open BZs to track the change? I've gone ahead and filed bugs. Specifically: * Bug 2022847 for RHEL 9.0 * Bug 2022848 for RHEL AV 8.6
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (virt:av bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4684