Hi Neal,

To maintain continuity with previous RHEL releases, we would like to keep the name of package as qemu-kvm in CentOS Stream and RHEL.
With the new Fedora -> CentOS Stream -> RHEL workflow in place, if our team agrees, this is something that can be changed in the next major RHEL release.

Thanks!

(In reply to Yash Mankad from comment #1)
> Hi Neal,
> 
> To maintain continuity with previous RHEL releases, we would like to keep
> the name of package as qemu-kvm in CentOS Stream and RHEL.
> With the new Fedora -> CentOS Stream -> RHEL workflow in place, if our team
> agrees, this is something that can be changed in the next major RHEL release.
> 

But this reasoning can be used to keep delaying fixing this tech debt. Why not just flip it back and use Obsoletes+Provides to replace the old packages?

We're very early in the RHEL 9 development period, and it'd be really great if we could fix this now.

We are not making the change you suggest in RHEL 9.

(In reply to Neal Gompa from comment #0)
> Description of problem:
> In upstream Fedora, the qemu-kvm package is simply just the qemu package.
> When CentOS Stream 9 was branched from Fedora Linux 34, we initially had the
> qemu package[1], but with the 5.2 rebase, it got renamed *back* to
> qemu-kvm[2]. In the interest of reducing deviation and making it easier for
> syncing between Fedora and CentOS/RHEL, it would be great if this rename
> could be dropped and we could ship with the packaging setup that's used in
> upstream Fedora, with virtual names for all the components matching what was
> previously provided in the qemu-kvm package.

FWIW the reasons why the 'qemu-kvm' package has a different name to start off with date back a while

 - The original RHEL-5/6 package was actually shipping source from the short lived qemu-kvm upstream fork, not primary qemu upstream
 - The 'qemu-kvm' package was shipping significantly less functionality than Fedora 'qemu', only the KVM related pieces
 - Users of RHEL are more focused on "KVM" as a term than "QEMU", so it helps to have 'KVM' in the package name when exposed in docs, bug trackers, etc

Obviously the first point doesn't apply any more. The last point is a non-technical one, but is reasonably important

The second point was and is still the most significant. It was desired to leave the "qemu" package name available, such that the community can decide to provide a full featured "qemu" package in EPEL repositories (or another add on repo of their choosing) with minimised clashes with RHEL qemu-kvm.

Also, RHEL has different scheme for naming binaries. While in Fedora you get qemu-system-x86_64 in RHEL you only get qemu-kvm and it's even placed in /usr/libexec. To me, that's bigger inconsistency than package naming.

(In reply to Daniel Berrangé from comment #5)
> (In reply to Neal Gompa from comment #0)
> > Description of problem:
> > In upstream Fedora, the qemu-kvm package is simply just the qemu package.
> > When CentOS Stream 9 was branched from Fedora Linux 34, we initially had the
> > qemu package[1], but with the 5.2 rebase, it got renamed *back* to
> > qemu-kvm[2]. In the interest of reducing deviation and making it easier for
> > syncing between Fedora and CentOS/RHEL, it would be great if this rename
> > could be dropped and we could ship with the packaging setup that's used in
> > upstream Fedora, with virtual names for all the components matching what was
> > previously provided in the qemu-kvm package.
> 
> FWIW the reasons why the 'qemu-kvm' package has a different name to start
> off with date back a while
> 
>  - The original RHEL-5/6 package was actually shipping source from the short
> lived qemu-kvm upstream fork, not primary qemu upstream
>  - The 'qemu-kvm' package was shipping significantly less functionality than
> Fedora 'qemu', only the KVM related pieces
>  - Users of RHEL are more focused on "KVM" as a term than "QEMU", so it
> helps to have 'KVM' in the package name when exposed in docs, bug trackers,
> etc
> 
> Obviously the first point doesn't apply any more. The last point is a
> non-technical one, but is reasonably important
> 
> The second point was and is still the most significant. It was desired to
> leave the "qemu" package name available, such that the community can decide
> to provide a full featured "qemu" package in EPEL repositories (or another
> add on repo of their choosing) with minimised clashes with RHEL qemu-kvm.

Okay, that makes sense. I wished I had known all this before, I didn't know any information about this other than an offhand comment from someone about it being tech debt that they'd like to see fixed.