qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 03/17] meson, cutils: allow non-relocatable installs


From: Paolo Bonzini
Subject: Re: [PATCH 03/17] meson, cutils: allow non-relocatable installs
Date: Mon, 16 Oct 2023 23:29:56 +0200

On Mon, Oct 16, 2023 at 1:55 PM Markus Armbruster <armbru@redhat.com> wrote:
> Out of curiosity: what's a non-relocatable install, and why should I
> care?

In a relocatable install if you move qemu-system-x86_64 from /usr/bin
to /home/armbru/bin, it will start looking for firmware in
/home/armbru/share/qemu.

In a non-relocatable install, it will keep looking for firmware in
/usr/share/qemu.

Whether that's something desirable or not... it depends.

On POSIX systems you almost never notice. Non-relocatability can help
if you want to do experiments with old firmware and new QEMU or vice
versa (because you can just upgrade/downgrade the firmware package,
and use rpm2cpio to extract the QEMU binaries outside /usr).

On the other hand Windows almost always wants relocatable installs,
which is why the whole idea was introduced in QEMU in fact. Newfangled
distribution mechanisms such as AppImage
(https://docs.appimage.org/reference/best-practices.html) and I think
NixOS (which installs each package in its own prefix, so you can
install multiple versions and switch at will the one that is symlinked
to /usr) also dislike using at runtime the absolute paths that were
established at build time.

Finally, the same code that handles relocation also lets you run QEMU
from the build tree and pick e.g. firmware files from the source tree
transparently. Even with this patch, that part of the code remains
active even if you configure with --disable-relocatable.

IOW: you probably have relied on the code, but if you have never
noticed in the past 3 years, it means that you probably need not care.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]