Hi Mathieu,
I know about that but taking it down to a suggest would be too much of a regression for users of local vrtiualization with gui.

Even I not really being a UI user often enough run it on a server with X forwarding to check bugs/features due to reports we get - so UI is used often enough (on servers as well).


== Dependencies ==
Lets make a diff of the depends first so that I can see what it exactly pulls on top of the old one:
$ diff  old new
0a1,2
> adwaita-icon-theme
> at-spi2-core
13a16,18
> gtk-update-icon-cache
> hicolor-icon-theme
> humanity-icon-theme
21a27,33
> libatk-bridge
> libatk
> libatk1.0-data
> libatspi
> libavahi-client
> libavahi-common-data
> libavahi-common
29a42,44
> libcolord
> libcroco
> libcups
32a48
> libepoxy
42a59,61
> libgtk
> libgtk-3-bin
> libgtk-3-common
51a71,73
> libjson-glib
> libjson-glib-1.0-common
> liblcms
53a76
> libncursesw
63a87
> libpcsclite
70a95,97
> librest
> librsvg
> librsvg2-common
72d98
< libsdl1.2debian
74a101
> libsoup-gnome
83a111
> libtinfo
91a120,121
> libvte
> libvte-2.91-common
92a123,125
> libwayland-client
> libwayland-cursor
> libwayland-egl
94a128,129
> libxcomposite
> libxcursor
98a134,137
> libxi
> libxinerama
> libxkbcommon
> libxrandr
99a139
> libxtst
102a143,152
> qemu-block-extra
> qemu-system-common
> qemu-system-data
> qemu-system-gui
> qemu-system-x
> qemu-utils
> seabios
> sharutils
> ubuntu-mono
> x11-common

Yeah I agree that is a lot :-/


== Reasons ==
Let me explain the reasons behind all of it.
The UI backend was SDL1 based.
But SDL1 support will be dropped upstream and GTK just is better in so many ways.
SDL2 is not yet in main and seems to take a while (and GTK is better for users)

This is the reasons why Debian chose gtk and we followed on that, to have something working well (better than SDL1) and being supportable (gtk in main)

== Recommends ==
In fact before the switch from SDL to GTK this wasn't a dependency at all - it was built in and you had no option but pulling in Deps - yet back then it was almost only libsdl1.2debian which obviously had a smaller footprint than now.

The separation into an extra package was done to allow size sensitive people e.g. minimized images to have qemu-system-gui (and due to that its depends) uninstallable.

But to further drop it to not be installed by default seems too much to me.
Not late in the cycle and not after Feature Freeze.

== What can we do ==
Well I can be convinced, so far it is just the two of us and our opinions :-)
For now I'd suggest:
- keep 18.10 as it is
- early in 19.04 drop the dependency to a suggest
- identify packages we know needing it badly (e.g. virt-manager) and add explicit dependencies to 
  -gui.

But this can be hard e.g. virt-manager never depended on qemu (as it can be remote) it 
only recommends libvirt which recommends qemu-kvm.
Neither adding qemu to virt-manager (incorrect) nor adding qemu-system-gui to libvirt (same 
problem as we have now) seems to make this any better.

=> Due to that I'm not even sure we should do it in early 18.10 :-/


At the moment I'm not yet sure how to make this much better cyphermox, I'm afraid to me the current Recommend dependency seems to be the best of all the bad alternatives available.

I'll discuss with the Team later to get a few other POV on this, please continue to discuss this with me and bring in others as needed.