Skip to content

pv-runtime: If we find /usr/local/share/drirc.d, mirror that in container

Simon McVittie requested to merge wip/smcv/drirc-location into master

  • pv-runtime: If we find /usr/local/share/drirc.d, mirror that in container

    If the user's graphics stack was not built with --prefix=/usr, for example a Mesa developer with a local installation of Mesa in --prefix=/usr/local, then we cannot necessarily expect it to load /usr/share/drirc.d in the container: it is more likely to have /usr/local/share/drirc.d compiled into it. To make sure that gets loaded, we need to mirror the path from the graphics provider inside the container.

    In fact we already did that, but only in a special case for Flatpak (in which graphics drivers are typically below /usr/lib/MULTIARCH/GL), so we can mostly just expand that special case to non-Flatpak installations.

    For Flatpak, we know that we always have a mutable sysroot, so the TAKE_FROM_PROVIDER_FLAGS_IF_CONTAINER_COMPATIBLE flag would be a no-op; but in non-Flatpak we could conceivably be in the older mode where we build up a long bubblewrap command-line, so we now want to pass in that flag, because being unable to share the data directory is better than just failing completely.

    Because something might conceivably be relying on us putting the data directory below /usr/share, we continue to do that as well.

    The indentation around the GHashTable in this commit is a bit weird, to keep the diff reviewable. It will be tidied up in a subsequent commit.

    Resolves: #77 (closed)

  • pv-runtime: Re-indent

/cc @zmike

This solves the situation where an entire Mesa build, including libGLX_mesa.so.0, is in the same non-/usr ${prefix} (which appears to be what @zmike has in #77 (closed)).

It does not solve the situation where only a partial Mesa build is used, for example using just the DRI modules, just the Vulkan ICDs, or just the EGL ICD, built for a non-system ${prefix}, in conjunction with a system copy of libGLX_mesa.so.0. @zmike: is that something that really happens and is really supported?

If we are going to try to address that scenario too (by going /foo/bar/lib64/dri/radeon_dri.so → /foo/bar/share/drirc.d, /one/two/lib/libEGL_mesa.so.0 → /one/two/share/drirc.d, /x/y/lib/x86_64-linux-gnu/libvulkan_lvp.so → /x/y/share and so on), then that will be a separate MR, because it's going to be significantly more code.

Edited by Simon McVittie

Merge request reports