On Mon, Oct 16, 2023 at 1:55 PM Markus Armbruster <arm...@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
