Re: qemu-system-x86 dependencies

[Michael Tokarev]

17.08.2023 08:10, Fourhundred Thecat wrote:
>  > On 2023-08-16 15:02, Fourhundred Thecat wrote:
> >  > On 2023-08-16 14:52, Michael Tokarev wrote:
> > > 16.08.2023 15:37, Philippe Mathieu-Daudé пишет:
> > > > Cc'ing Michael
> > why does qemu depend on sound and gstreamer and wayland libraries?
> > After all, i am just trying to run VMs on my hypervisor.
> >
> > If I remember correctly, my previous installation on Debian 10,
> > qemu-system-x86 had no such dependencies.
> >
> > Seems to me like trying to install openssh-server, but it needs full
> > gnome environment libraries.
>
> sorry if my question offended people.

Yes, your question did.  Declaring a few dependencies which you personally
dislike as "madness" does not help.

> Perhaps there is a good reason for these dependencies, which i don't see?
>
> Also, I am told that Arch has split all these into separate packages:
>
> https://archlinux.org/packages/?sort=&repo=Extra&q=qemu&maintainer=&flagged=
>
> So it looks like my original question might be Debian specific?

As I always ask people asking similar questions (there are a lot): which
problem are you trying to solve?

Do you know how many binaries, for example, coreutils package contain?
Just imagine how many useless binaries are installed on your machine!
This package definitely needs to be split into single package per binary,
with proper dependencies between them and for every other package out
there which uses any binary from coreutils.  Or else it is a complete
waste of disk space, and it also needs security support/updating even
if a bug is found in an unused binary..

I know this attitude. I've been like this too, when I just come to *nix
and noticed how many various files are installed on the system.  No, this
is not how the system works.

Pathological example aside, - most distributions out there enable all
(or actually most) features of software they include. If you want fine
control, you can take a look at gentoo and their 'use' flags.  You can
build software exactly for your use case, with only the features your
use case needs.  This works.  Also, this takes time, - to figure out
which features are needed, which are supported as 'use' flags, and
finally to build stuff.

Some features in qemu can be build modular.  Some (eg usb device support,
hello libusb dependency) can not.  For things which can be made modular,
Some distributions ship each possible qemu module within its own package.
In debian I've choosen a mixed approach, by grouping some things together
to make life of users *simpler* yet to allow eliminating large deps
(like whole X11 stack for the gui part).  It's the same thing - by making
too many packages you make it too difficult for the users to use some
features, because it's impossible to figure out which additional packages
they need to install, - to eliminate the "usage madness", so to say, when
something should work according to qemu docs but it doesn't due to missing
package and there's no one here to help figure out which package it is.
Even after I've split qemu-block-extra package with some less-often-used
block drivers (each with its own deps), users started filing bugs saying
this or that block backend does not work, - giving headache and frustration
both to the users and to me as the maintainer.

Sure thing what you've asked is debian-specific, because these are all debian
packages, be it qemu or anything else.  And sure qemu-system-x86 (which is
another trade-off, - I don't ship package per architecture in debian, but
group "similar" architectures together) is a debian package.

An example, qemu in debian does not depend on gstreamer (and e.g. libopus is
pulled by gstreamer).  On my servers which run qemu-system-x86, gstreamer is
not installed.   For the audio-related "issue", there are 2 dependencies, -
libsndio and libausound, both small libraries without much deps.  These,
together with a few other modules in qemu-system-common, are often used on
a headless server to run regular guest systems, - I see no reason to split
that stuff further, and it will definitely make things more difficult for
regular (incl. headless) usage.

If you dislike the trade-off I've choosen, feel free to switch to some other
distribution (e.g. gentoo), or file bugs in debian bts with good reason for
each change you want to be made.

/mjt