Re: qemu-system-x86 dependencies

Re: qemu-system-x86 dependencies

[Philippe Mathieu-Daudé]

Cc'ing Michael

On 16/8/23 13:52, Fourhundred Thecat wrote:
> Hello,
> 
> I am trying to install qemu-system-x86 on Debian 12.
> 
> But through the dependency cascade, it wants to install sound
> infrastructure with gstreamer libraries. Which leads to absurd
> dependencies, such as:
> 
>    libasound2
>    libgstreamer-plugins-base1.0-0
>    libopus0
>    libwayland-server0
>    libusb-1.0-0
> 
> Does this madness come from Debian distribution, or from upstream?
> 
> I am just trying to set up kvm/qemu to run virtual machines on a server.
> 
> thank you,
> 
> 
> 
> 
> 

Re: qemu-system-x86 dependencies

[Michael Tokarev]

16.08.2023 15:37, Philippe Mathieu-Daudé пишет:
> Cc'ing Michael
> 
> On 16/8/23 13:52, Fourhundred Thecat wrote:
>> Hello,
>>
>> I am trying to install qemu-system-x86 on Debian 12.
>>
>> But through the dependency cascade, it wants to install sound
>> infrastructure with gstreamer libraries. Which leads to absurd
>> dependencies, such as:
>>
>>    libasound2
>>    libgstreamer-plugins-base1.0-0
>>    libopus0
>>    libwayland-server0
>>    libusb-1.0-0
>>
>> Does this madness come from Debian distribution, or from upstream?

I don't know which madness you're talking about. Is it qemu upstream madness
or debian distribution madness?  Maybe if you were be a bit more specific
and share your definition of madness, things would be more clear.  But with
either of the mentioned madness, it might be neither of us are able to
understand, being both mad.

/mjt

Re: qemu-system-x86 dependencies

[Fourhundred Thecat]

 > On 2023-08-16 14:52, Michael Tokarev wrote:
> 16.08.2023 15:37, Philippe Mathieu-Daudé пишет:
>> Cc'ing Michael
>>
>> On 16/8/23 13:52, Fourhundred Thecat wrote:
>>> Hello,
>>>
>>> I am trying to install qemu-system-x86 on Debian 12.
>>>
>>> But through the dependency cascade, it wants to install sound
>>> infrastructure with gstreamer libraries. Which leads to absurd
>>> dependencies, such as:
>>>
>>>    libasound2
>>>    libgstreamer-plugins-base1.0-0
>>>    libopus0
>>>    libwayland-server0
>>>    libusb-1.0-0
>>>
>>> Does this madness come from Debian distribution, or from upstream?
>
> I don't know which madness you're talking about. Is it qemu upstream madness
> or debian distribution madness?  Maybe if you were be a bit more specific
> and share your definition of madness, things would be more clear.  But with
> either of the mentioned madness, it might be neither of us are able to
> understand, being both mad.

what I meant is:
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.

Re: qemu-system-x86 dependencies

[Fourhundred Thecat]

 > 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.

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?

Re: qemu-system-x86 dependencies

[Paul Menzel]

Dear Fourhundred,


Am 17.08.23 um 07:10 schrieb Fourhundred Thecat:
>  > 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.
> 
> 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?

Please tell us, how you actually build QEMU (in the past). Building QEMU 
from upstream sources and configuring it with minimal options, why do 
the dependencies from the Debian package matter at all?


Kind regards,

Paul

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