You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of priority for extensions with the same ID but different branches is backward.
In the first part of flatpak_run_add_extension_args(), it bind mounts all available extensions to their named subdirectories. It does this in priority order, which means it will mount a lower-priority branch over top of a higher-priority one. In the second part, it makes symlinks for the highest-priority extension, but in this case, those end up pointing to the lowest-priority branch.
org.freedesktop.Platform.GL.default//23.08-extra currently set a negative (lower) priority, which is not how that was intended to work, though it doesn't seem to be documented anywhere.
It's too late to fix the meaning of priority, so do we just document the current behavior and live with it?
My preference would be to disregard priority between branches and use the order they're listed in versions instead. In the GL extension point, they're currently listed as 23.08;23.08-extra;1.4, so we'd have to make later higher priority. This would match the current implicit behavior when priorities are equal.
The opposite might be nicer, but that would require changing every GL and GL32 extension point, and also considering any potential breakage for other extension points. I notice that the openh264 extension point has 2.2.0beta;2.2.0, so the beta version isn't used unless you remove the stable one. I don't expect that was intended.
The text was updated successfully, but these errors were encountered:
The current implementation of priority for extensions with the same ID but different branches is backward.
In the first part of
flatpak_run_add_extension_args()
, it bind mounts all available extensions to their named subdirectories. It does this in priority order, which means it will mount a lower-priority branch over top of a higher-priority one. In the second part, it makes symlinks for the highest-priority extension, but in this case, those end up pointing to the lowest-priority branch.org.freedesktop.Platform.GL.default//23.08-extra
currently set a negative (lower) priority, which is not how that was intended to work, though it doesn't seem to be documented anywhere.It's too late to fix the meaning of priority, so do we just document the current behavior and live with it?
My preference would be to disregard priority between branches and use the order they're listed in
versions
instead. In the GL extension point, they're currently listed as23.08;23.08-extra;1.4
, so we'd have to make later higher priority. This would match the current implicit behavior when priorities are equal.The opposite might be nicer, but that would require changing every GL and GL32 extension point, and also considering any potential breakage for other extension points. I notice that the openh264 extension point has
2.2.0beta;2.2.0
, so the beta version isn't used unless you remove the stable one. I don't expect that was intended.The text was updated successfully, but these errors were encountered: