Open ghost opened 4 years ago
Definitely the second option for the time being. While implementing the third option would be the cleanest approach in my opinion, I don't think there's a lot of value to be gained from it considering that MangoHud is one of its kind on Flathub for now; however, should there be more Vulkan layers available, it could be revisited in the future.
MangoHud is one of its kind
I see vkBasalt as another candidate to flathub, but it's current make-based forced-multilib build system makes it almost impossible to package.
In this case, I would opt in for the third option, and notify the vkBasalt developer of the obstacle to packaging it in the Flatpak format - perhaps there is a common ground to be found. https://github.com/DadSchoorse/vkBasalt/issues/16
The developer is aware of the build system situation, they're just not willing to change it. It's preventing not only flatpak but probably all distro packaging formats (except maybe AUR).
Are there other notable candidates? If not, re-using this extensions as-is is the way to go for the present. I might be wrong, though; I have very limited understanding of an impact that going with either of options would have on the ease of maintainability.
Are there other notable candidates?
Take look at libstrangle. Also new version supposed to "hopefully aids anyone trying to package the software".
@Bryophyllum well, as you noted, adding a runtime extension point is the cleanest approach and multiple apps can benefit from it. While plugging Steam's extension to Lutris is easier and surely faster, it may pose problems since Lutris and Steam run in different environments.
@tim77 Hmm. This is a perfect candidate. Lutris'es Fps limiter uses this layer/library, and it happens that this feature is missing from the Lutris Flatpak.
@gasinvein Thank you for the reflection. That's a valid concern.
@gasinvein Does this issue align with our goal? https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/964
@Bryophyllum it does. Looks like the original proposal was exactly what I suggested above, i.e. a dedicated extension point for 3rd party vulkan layers in the runtime.
Well, I see several options:
com.valvesoftware.Steam...
for Lutris, so that this extension will be reused as is