Paolo Bonzini <pbonz...@redhat.com> writes: > 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.
I think this would make a fine commit message body :) Thanks!
