runtime: Correctly handle data dirs when in a Flatpak environment
-
Expose the modified /app to the subsandbox, if any
If we modify "/app" we want to bind it to the new subsandbox instead of always binding an empty directory.
-
When we are in a Flatpak environment there are two issues:
- It's common to have multiple data directory, usually one for every multiarch
- If we bind the data directory in "/usr/share/${dir_basename}" there is no guarantee that it will be in the library search path
For this reason we avoid raising a warning if we have multiple data directory and also we bind them preserving their original path.
Merge request reports
Activity
With
LIBGL_DEBUG=verbose
I verified that the bindeddrirc.d
in/usr/share/drirc.d
was not picked up by the mesa driver.Additionally when we are in
pv_runtime_finish_lib_data()
we only know about the realdrirc.d
directory that is usually located in/app/lib/i386-linux-gnu/GL/default/share/drirc.d
, fori386
. Also this path is not in the library search patch because apparently only/usr/lib/i386-linux-gnu/GL/default/share/drirc.d
is.In the freedesktop.org runtime this is handled by creating a symlink
/usr/lib/i386-linux-gnu -> ../../app/lib/i386-linux-gnu
.For this reason if we detect that we are trying to bind a path in
/app/lib/*
, we also check if the counterpart in/usr/lib
is the same directory, and if it is we bind this too.mentioned in merge request !290 (merged)
mentioned in commit d263dabf