FS#74687 - [gnome-boxes] requires qemu-desktop, which conflicts qemu-full

Attached to Project: Arch Linux
Opened by Alexandre Bury (gyscos) - Monday, 09 May 2022, 13:53 GMT
Last edited by David Runge (dvzrv) - Sunday, 20 August 2023, 21:39 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jelle van der Waa (jelly)
David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

Description:

qemu-full conflicts with qemu-desktop.
qemu-desktop is explicitly required by gnome-boxes.

As a result, it is currently impossible to install both qemu-full and gnome-boxes. Is that the intended behaviour?
The announcement made it sound like qemu-full should be a superset of qemu-desktop. Maybe it should `provide` qemu-desktop?

Additional info:
* gnome-boxes 42.0.1-2
* qemu-desktop 7.0.0-9
* qemu-full 7.0.0-9

Steps to reproduce:

pacman -S gnome-boxes qemu-full
This task depends upon

Closed by  David Runge (dvzrv)
Sunday, 20 August 2023, 21:39 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with qemu 8.0.4-2, as qemu-desktop no longer conflicts with qemu-base and qemu-full
Comment by Alexandre Bury (gyscos) - Monday, 09 May 2022, 15:46 GMT
(Thanks for the title fix! I did not find how to edit the post afterwards.)
Comment by David Runge (dvzrv) - Monday, 09 May 2022, 15:48 GMT
@gyscos: Thanks for the ticket.

Qemu is provided by qemu-{base,desktop,full} in varying feature richness.

In theory (and also quite practically) gnome-boxes could rely on qemu, *but* it requires a few graphical backends, that need to be found out and added specifically for this to work.
FWIW, both qemu-desktop and qemu-full would satisfy this, but qemu-base (on its own) can not, as it is meant for headless systems.
Comment by Alexandre Bury (gyscos) - Monday, 09 May 2022, 15:50 GMT
Yes, that's what I gathered from the situation.

I think the solutions are:

* Be more precise in gnome-boxes dependencies to exactly list the actual required packages, which could be provided by either qemu-full or qemu-desktop (or even no metapackage at all).
* Make a new qemu-gui virtual dependency. Have both qemu-desktop and qemu-full provide this. Make gnome-boxes depend on this instead of qemu-desktop.
* Have qemu-full be compatible with qemu-desktop (since both are just meta packages)
* Have qemy-full provide qemu-desktop.
Comment by David Runge (dvzrv) - Monday, 09 May 2022, 16:13 GMT
I think only the first choice is really a viable solution for now, as anything else will become rather complicated once we more clearly define the base set of packages for qemu (currently that is, what qemu-base provides I guess).

One of the biggest differences between qemu-base and qemu-{desktop,full} are

```
qemu-ui-dbus
qemu-ui-egl-headless
qemu-ui-gtk
qemu-ui-opengl
qemu-ui-sdl
qemu-vhost-user-gpu
```

I believe replacing qemu-desktop with the above and qemu would allow for using any qemu provider.

The other solutions are rather complicated to maintain, especially when meta packages start to provide one another etc.
Comment by David Runge (dvzrv) - Monday, 09 May 2022, 16:15 GMT
Ah, we should not forget about the audio drivers of course!

```
qemu-audio-alsa
qemu-audio-dbus
qemu-audio-jack
qemu-audio-oss
qemu-audio-pa
qemu-audio-sdl
```

The above would also need to be added, as they are not provided by qemu-base.
Comment by Toolybird (Toolybird) - Monday, 06 June 2022, 22:00 GMT
The more I stare at this, the more I think the current QEMU meta package structure is sub-optimal.

We now have a fine grained split setup which lends itself *perfectly* to a much simpler "superset" pkg arrangement. ie:

qemu-base
qemu-desktop (depends on qemu-base)
qemu-emulators-full
qemu-full (depends on qemu-desktop, qemu-emulators-full)

AFAICT, this is much saner and solves all the problems reported so far.

I have attached a patch as a proof-of-concept. It notably:

- strips qemu-base back to barebones which makes it truly headless
- pins optdepends to qemu-base which makes the whole optdepends setup less weird
- removes "conflicts" which means all meta packages can be installed together
- removes some "niche" pkgs from qemu-desktop (they are of course still optdepends and also part of qemu-full)

Any thoughts?

I am testing this out in my personal build will report back if any issues crop up.
Comment by e (cer0) - Saturday, 11 June 2022, 14:26 GMT
Maybe is a libvirt issue?

Downgrading from 1:8.4.0-1 to 1:8.3.0-1 solved the issue for me, as indicated in this thread

https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/806
Comment by Toolybird (Toolybird) - Wednesday, 15 June 2022, 06:53 GMT
> I am testing this out in my personal build will report back if any issues crop up.

All good, no issues whatsoever. Arch should look seriously at this.

> Maybe is a libvirt issue?
> ...
> https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/806

Umm, this Arch bug is about distro packaging of QEMU. Any other gnome-boxes issues are completely separate.

But nevertheless I had a look-see. It seems libvirt added some additional validation in libvirt-8.4.0 [1]. It would appear gnome-boxes is creating invalid VM configs and is getting tripped up by the new validation. Therefore I guess it needs to be fixed in gnome-boxes (Note: I don't use use gnome-boxes myself).

[1] https://gitlab.com/libvirt/libvirt/-/commit/36e86dbf
Comment by David Runge (dvzrv) - Wednesday, 15 June 2022, 08:48 GMT
@Toolybird: Thanks for the investigation.

> > I am testing this out in my personal build will report back if any issues crop up.
> All good, no issues whatsoever. Arch should look seriously at this.

I don't quite understand the rationale behind your change. The current setup is done in such a way so that the user is able to install "qemu" (being asked which one) and have a single place where to lookup optdepends (no matter which scope of qemu is installed) while being able to add components in a modular fashion. In your paradigm the only place where optdepends are tracked is qemu-base, which is not very intuitive if one does not know which components are which and has to go backtracking on the dependencies.

In your proposed changes you have removed qemu-audio-spice, qemu-block-{curl,dmg,nfs,ssh}, qemu-chardev-spice, qemu-hw-display-{qxl,virtio-gpu{,-{gl,pci,pci-gl}}}, qemu-hw-display-virtio-vga{,-gl}, qemu-hw-s390x-virtio-gpu-ccw, qemu-hw-usb-{host,redirect,smartcard}, qemu-pr-helper, qemu-tools and qemu-ui-{curses,spice-{app,core}} from qemu-base, but those components were all part of qemu-headless before (which changes its feature set).

Either way, I'd appreciate this in a separate ticket, because it has only indirectly to do with gnome-boxes not declaring its dependencies correctly.

> Umm, this Arch bug is about distro packaging of QEMU. Any other gnome-boxes issues are completely separate.

This issue is actually about gnome-boxes not declaring the right dependencies.
Comment by Toolybird (Toolybird) - Thursday, 16 June 2022, 04:27 GMT
> Either way, I'd appreciate this in a separate ticket

No worries. I've filed this separately as  FS#75078 

(Sidenote: the list of open QEMU tickets is starting to grow. I would be happy to take on some Arch bug wrangling duties if someone would like to make it happen. I've been active in the Arch bug tracker for approx' 5 years and have hopefully demonstrated enough competence and trust.)

> This issue is actually about gnome-boxes not declaring the right dependencies.

Yes, but please bear in mind if the QEMU meta packages are restructured as per my prosposal, current gnome-boxes deps are fine and this ticket goes away.
Comment by Josef Mutzenbacher (Joe2020) - Wednesday, 02 November 2022, 21:29 GMT
To me it seems suboptimal that a package in "extra" pulls in dependencies from "community".

On my system, "pacman -S qemu-base" pulls (indirectly) in:

community/capstone
community/dtc
community/libnfs
community/libslirp
community/multipath-tools

Though this doesn't cause a real problem, I think it is better to point at it...
Generally spoken, I would prefer a qemu-base with as few dependencies as possible. No ui, no opengl, no spice, no audio... all this should be "optional".
Comment by David Runge (dvzrv) - Wednesday, 02 November 2022, 21:53 GMT
@Joe2020: Apart from that being tangential to this ticket: We are about to merge extra and community [1].

> Generally spoken, I would prefer a qemu-base with as few dependencies as possible. No ui, no opengl, no spice, no audio... all this should be "optional".

As we want to only build once, I don't think our PKGBUILD will change significantly in the future.
You are of course free to create your own meta package that achieves what you describe/want.
To my knowledge only opengl somehow gets pulled in because of that and I think there are worse things than a few MiB of libs.


In regards to this ticket: I will try to rebuild gnome-boxes with proper dependency resolution in the coming days.

[1] https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0014-merge-package-repos.rst
Comment by Toolybird (Toolybird) - Sunday, 18 December 2022, 00:28 GMT
Dupe  FS#76863 
Comment by David Runge (dvzrv) - Saturday, 12 August 2023, 09:08 GMT
Please check whether qemu 8.0.4-1 in [extra-testing] fixes this issue for you.

Loading...