On Thu, Apr 27, 2023 at 02:12:59PM +0200, Thomas Huth wrote: > On 27/04/2023 10.33, Daniel P. Berrangé wrote: > > On Thu, Apr 27, 2023 at 10:31:00AM +0200, Paolo Bonzini wrote: > > > On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berra...@redhat.com> > > > wrote: > > > > > I wonder if we should take this a step further and rename > > > > > qemu-system-x86_64 > > > > > to qemu-system-x86! Distros can if they wish create symlinks to both > > > > > qemu-system-i386 and qemu-system-x86_64. > > > > > > > > I can't help feeling this just creates a new upgrade burden for distros > > > > for no obvious win. > > > > > > We can create the symlinks on install as well during the deprecation > > > period. It doesn't have to be done by distros. > > > > What's the actual win though ? Why would anyone want to create guests > > using qemu-system-x86, if both qemu-system-i386 / qemu-system-x86_64 > > still exist indefinitely for backwards compat. > > We could deprecate the old wrappers at one point in time, so we would > finally have a cleaner interface.
At the cost of breaking compat every single script and doc that referrs to the historical binaries. I think incompatible changes are worth it, but only if we associate them with the a approach to qemu system emulator binaries, as that's where we'll get a compelling benefit. Fiddling around with the existing binaries is creating pain for little gain IMHO. > > What does having a > > qemu-system-x86 add that can't be achieve just though hardlink > > between the two existing binaries ? > > We'd finally have a binary with saner default settings compared to the > backlevel "pc" machine type that we have as a default now? On the libvirt side we would have to ensure there was no change in defaults regardles of what he QEMU binary did. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
