-
-
Notifications
You must be signed in to change notification settings - Fork 390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: subsandbox chooses extensions independently of original app #4539
Labels
Comments
3 tasks
Closed
4 tasks
Resolving #5278 would solve 95% of this, and might be easier than the approach I had started working on. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Checklist
Flatpak version
1.12.2
What Linux distribution are you using?
Debian
Linux distribution version
unstable
What architecture are you using?
x86_64
How to reproduce
FLATPAK_GL_DRIVERS=mesa-git flatpak run com.valvesoftware.Steam
flatpak-spawn
(or Steam'spressure-vessel-launch
, which uses the same D-Bus API) to start a new subsandbox, and do not use--latest-version
orFLATPAK_SPAWN_FLAGS_LATEST_VERSION
Expected Behavior
The subsandbox has the same
/app
,/usr
and extensions as the original app, at the same commits.If using #4018 via
pressure-vessel-launch
, then the expected result is that/run/parent/app
and/run/parent/usr
are the same as the original app's/app
and/usr
, including all extensions; for example if the original app hasmesa-git
mounted below/usr
, then the subsandbox hasmesa-git
mounted below/run/parent/usr
.Actual Behavior
As expected,
flatpak-portal
tellsflatpak run
to use the same exact commit as the original app's/app
for the subsandbox's/app
or/run/parent/app
.As expected,
flatpak-portal
tellsflatpak run
to use the same exact commit as the original app's/usr
for the subsandbox's/usr
or/run/parent/usr
.However,
flatpak-portal
does not tellflatpak run
to use the same extensions and extension commits as the original app's extensions (and in fact there is no mechanism to do so), soflatpak run
will compute which extensions to mount from first principles. In particular, the GL stack below/run/parent/usr
in the subsandbox will be the default GL stack, even if the original app was forced to use a non-default GL stack.This leads to ValveSoftware/steam-runtime#474, because pressure-vessel (SteamLinuxRuntime) relies on the graphics stack in the original app (Steam) matching the graphics stack in the subsandbox that it creates.
Additional Information
From source code inspection, there is another, closely related, failure mode. If you run an app, leave it running, and upgrade some of its extensions before creating the subsandbox, the desired result is that the subsandbox gets the old versions of the extensions (matching the original app), but the actual result is that the subsandbox gets the new (upgraded) versions.
I've started to look into solving this by using the
FLATPAK_METADATA_KEY_APP_EXTENSIONS
andFLATPAK_METADATA_KEY_RUNTIME_EXTENSIONS
from the/.flatpak-info
to populate the subsandbox's list of extensions, but it isn't straightforward to match them to extension points, so it's going to need some more work and I don't have a MR ready yet.The text was updated successfully, but these errors were encountered: