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: Markus Armbruster
Subject: Re: [PATCH 03/17] meson, cutils: allow non-relocatable installs
Date: Tue, 17 Oct 2023 07:46:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Paolo Bonzini <pbonzini@redhat.com> writes:

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

I think this would make a fine commit message body :)

Thanks!




reply via email to

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