Add RFC: Flatpak (Linux) #21
Conversation
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
The same applies to literally every packager available in linux at the current time. Perhaps you can compare flatpak to existing options in terms of real tangible benefits instead of speaking in platitudes.
This is mostly opposed to the functions of OBS which is to be tightly integrated into the desktop environment (i.e. capturing it). Isolation typically works to defeat the purpose of OBS. So im not sure how this is a benefit. As an example OBS typically relies on driver provided functionality like opengl and vaapi and nvenc. Vaapi is known to break compatibility with old drivers so trying to isolate the obs userland would only cause more breakages then relying on packagers. As a second example downstream flatpak requires xdg-portal extension because normal x capture is presumably blocked in the flatpak runtime environment (maybe it happens to work).
I dont see any reason to add it unless we intend to support it as a releasable package. It would only bait people into thinking we support it if we add it otherwise. |
|
Moving the contents of obsproject/obs-studio#2752 to here. This is the proposed Flatpak manifest file. I'm personally excited with the prospects of Flatpak support in regards to the development experience as well. Flatpak allows a "clone & run" approach, pretty much like this. |
|
as an example of how isolation in flatpak itself is also misaligned with obs. Consider from the proposed manifest rule. Who maintains these? How do we know what new features might require? Are we going to get a new fun "talk-name" to add for ever DE someone can think up? What about Jack (looking at pulseaudio). Does ALSA bypass this? If the only permissions to add were those maintained by flatpak and freedesktop it might seem almost reasonable. However it obviously depends on per DE magic which is not appealing. And of course in its goal of isolation flatpak obfuscates the actual DE being run, preventing logging for providing useful information (since we have established that flatpak is dependent on DEs). e.g. obs will log |
|
it would be wonderful to have OBS Studio on Flathub officially, the current version works very well! |
|
As I understand it, the current build on Flathub has some third-party plugins bundled with it, such as obs-linuxbrowser rather than obs-browser. Apparently there are some features of obs-linuxbrowser that aren't on obs-browser yet, such as the ability to load CSS from an external file. If that transition is to be made nicely, it would be nice for those features to be submitted to obs-browser. |
When I proposed this RFC, I wasn't necessarily thinking about publishing OBS Studio on Flathub directly, but that would be wonderful indeed. What I had in mind is just adding a Flatpak manifest file to OBS Studio itself, which would then go through a period of more extensive testing, before we can think of publishing it somewhere.
Those are good points, I absolutely agree that the Flathub build shouldn't ship plugins that are not default. I'm not proud that one of these out-of-tree plugins is my own As for the I believe the moment Flathub doesn't need to ship any out-of-plugin by default, is the moment OBS Studio should consider publishing to it (if desired, of course). But I don't personally think it blocks us from having a Flatpak manifest available before that. |
|
I'd like to take a step back and address @kkartaltepe's concerns. Sorry this is a wall of text, but I hope to shed some light on the points you raised.
As a developer the sandboxing side of Flathub aimed at reducing the gap between "works on my machine" and "works on anyone else's machine". As such it tries to promote specific, reusable and reproducible builds and a common runtime, whilst still being "desktop oriented" with fairly seamless integration for video drivers, portals, acceptable desktop permissions etc. My intention is not to advocate for Flatpak in exclusion of other technologies. but there are some good reasons for having a Flatpak manifest available:
A properly sandboxed application requires tight integration to the platform, by using the appropriate screencasting APIs. In this case, as discussed on Discord, the best API we have for now is the XDG Desktop portal. Specifically, the ScreenCast interface. By using these APIs, OBS Studio will work inside and outside sandboxes (be it Flatpak, Snap, or AppImage), on Wayland and X11, on all desktops that implement it. Right now, the ScreenCast interface is implemented by GNOME, KDE, and wlroots, which covers a fair share of desktop users. Desktops that don't implement this interface can always fallback to good old X11 which works without change.
The
If you're talking about the permissions, it's OBS Studio. We control which permissions we require in order to function correctly.
I don't think so. The session management D-Bus specifically is a mess, as the result of a historical process. But it's a controlled mess. OBS Studio already support the standard and legacy D-Bus interfaces, and doesn't need to support more than that.
Jack is an open question, but there is rudimentary support for it. Admittedly, I just grabbed Flathub's manifest, and stripped out of what's unnecessary. If you look at the bottom of the file, you can appreciate the following lines: "config-opts": [
"-DCMAKE_BUILD_TYPE=Release",
"-DUNIX_STRUCTURE=ON",
"-DUSE_XDG=ON",
"-DDISABLE_ALSA=ON",
"-DDISABLE_JACK=ON",
"-DENABLE_PULSEAUDIO=ON",
"-DENABLE_WAYLAND=ON",
"-DWITH_RTMPS=ON"
],That is, when building as a Flatpak, OBS Studio explicitly disables Jack and ALSA. There are ongoing discussions around seamlessly enabling these in Flatpak, with ALSA more likely in the very near term. Jack is likely to be supported with pipewire compatibility.
These permissions aren't "maintained by flatpak and freedesktop", we may have a misunderstanding. The permissions are the application defining the surface area that it needs and is willing to support. Or to put it another way, this moves the implicit contract into something that's explicit. There are certainly some reasons why Flatpak may not be an ideal fit for the default distribution method for OBS Studio, whilst the Mesa, nvenc etc. story is pretty mature there are certainly some weakness' in Jack and ALSA support currently. These are areas that are actively being worked on. However for the majority of Linux cases this can be helpful in reducing the frustration with distributed development. |
|
We also have several people working on an AppImage package. What advantages does this offer over AppImage? I believe this might be part of what @kkartaltepe was asking. What makes Flapak better than any of the other options? Why should we pick this one? Your comments seem to be addressing what the benefits of That said, to be clear, I have no strong opinion on any of these solutions. I think having a platform-agnostic package that can be installed in any distribution is a positive thing for the project, but I don't want us running down multiple roads and incurring a heavy maintenance cost for what is effectively the same thing. I'm afraid this might turn in to a personal opinion debate when it comes to Flatpak vs anything else, but I am curious to hear the opinions regardless. |
|
Flatpak and other forms of packaging are on the rise. I found this idea very positive. |
|
Well, I was trying to avoid this kind of comparison. I don't feel comfortable in talking about one technology in detriment of others. Thus allow me to fully embrace that this comment is very much my own personal view of these technologies. I don't think AppImage is really a solution to the problem at hand. AppImage is not an app distribution mechanism, it's an app bundling mechanism. Once you bundle an AppImage with a set of libraries, the bundle is stuck with that forever. If that doesn't sound too bad, let me remind everyone of the existence of a nightmare called VAAPI. Flatpak doesn't bundle anything to the application's executable, and it can do that thanks to runtimes. These low-level libraries are provided by the runtimes, and there is a team of volunteers and paid developers maintaining it. It's less the developer has to maintain and less security concern for the end user. I mentioned Flatpak runtimes, and this is a key aspect of it. AppImage doesn't really have the concept of a runtime (i.e. "what does this app needs in order to run"), so you have to literally boot your computer with the oldest system you want to support, and build the AppImage inside it. This is not a joke, this is a documented best practice (!). Flatpaks don't need any of this because it addresses the true problem behind it: it isolates the application from the host system for real, at glibc level. It is, by design, guaranteed to work everywhere. With Flatpak, updates are a fundamental part of the technology. If the app doesn't self-update, that's ok; if the app self-updates, that's ok too, Flatpak supports both. AppImage doesn't have automatic app updates, and if OBS Studio wants that on Linux, it'll have to write its own update mechanism. One could argue that you can have AppImage updates, and that's true as long as you add a bunch of extra stuff to your host system. AppImage is factually not distro-agnostic, it just works well enough on many of them. Flatpak has deep desktop integration by default. Installing a Flatpak app shows it in the app list, it can export D-Bus interfaces, it has bash completion; basically, everything you expect of an app. This is something that AppImage doesn't have. AppImage wasn't built with that in mind. Again, if you really want to, you can, but you need to add a bunch of extra stuff to your system (but it has quite considerable drawbacks). You have multiple choices on how you want your desktop applications to be half integrated into your desktop, pick your poison. Flatpak is far easier to build because it doesn't ask require you to modify your program, or to use any specific version of any fundamental library, or even to binary-path the application. Flatpak doesn't force the application to statically link to anything. At last, I'd like to mention that Flatpak can improve CI too. CI won't need to build and test OBS Studio on multiple distros, or pick one distro and run on it. By having an official, or even semi-official, distribution platform (for Flatpak, that's Flathub), OBS Studio can also avoid people running different versions built in different ways on old or exotic distros that have incompatible or unreproducible environments. |
|
To add some comments to the post above: I used to be a huge fan of AppImages, but I ended up dropping them in favor of Flatpaks for the following reasons:
This isn't to say it's perfect (though nothing is), but I've definitely had far less trouble both building and managing Flatpaks instead, and even the most complicated stuff I've had to do generally didn't take as long as trying to make AppImages work consistently. |
|
@GeorgesStavracas you said a lot of wrong things:
In Flatpak, an Application is linked to runtime until ap updates, is exactly same thing but with files that application don't need
You not understand the concept, since glibc has retrocompatibility, once time you bundle the application on oldest base system, you don't need bundle glibc, do this will save up to 8 - 15 MB on resulting AppImage. The most troubles with AppImages is because its was build on newer system but doesn't bundle glibc
Not exactly, for e.g if for some reason
Wrong again, AppImages can easy self update just pass provide a .zsync file on HTTPS server and call zsync under AppDir, just chdir do AppImage location, for e.g. reading "APPIMAGE" environment variable, is very easy to do,
This is needed by Flatpak, no in AppImage, an external updates requires a single file, to install and update Flatpak, the user will need 104 files according Debian: To update AppImages just a single file:
Flatpak also
ApImages also export D-Bus interfaces, and if developer wants shows it in the app list after first run (similar to Windows, Mac OS X, Android...), Flatpaks doesn't have a lot of visual integrations, is a significant drawback especially media content apps, Qt Applications has a messy design outside LXQT and GTK apps looks like a alien outside GNOME OSes (Endless OS, Fedora Silverblue...) without work arounds |
You're mistaken here. Application ships only libraries which are outside the runtime. Runtime is updated separately, so maintainer doesn't need to worry about core libraries such as graphical toolkit or SSL.
You have proved yourself it's not portable, not to mention it implies being bound to a distribution shipping ancient software, with everything else that comes included. Old GCC, old curl, old ffmpeg. I'm also happy to notice that you conveniently skipped the part about musl distributions.
Both Debian and Deepin are perfectly fine with flatpak versions shipped in their repositories. There are newer releases available in backports but it just means missing optional new features.
It's very simple! Just serve a file from a server, chdir, call zsync, set proper environment variable and you are done! It sounds just ridiculous when compared to the integrated experience Flatpak provides with Flathub, completely ignoring integrated CI and CDN.
Yes, these are distribution maintained packages providing core functionality of Flatpak, including support and security fixes for time frame decided by Debian. I'll take it any day over a random binary which promises to do the correct thing.
Have you ever actually used Flatpak or just spreading FUD? After initial setup (which requires relogin for distributions which don't come with it pre-installed), desktop launchers are visible instantly after an application is installed. Theming is tricky to get right in a secure way, so Flatpak will instead look for the specific theme in the repository and install it as an extension. In general, you are comparing apples to oranges. Even Microsoft realized that run-this-random-exe-from-internet is a flawed idea and added an official application store with Windows 10 and started working on sandboxing applications. |
Nope, apps is separated from runtime, but still linked by this, so if a application depends on org.kde.Platform version 5.14 they will run with these libs until an application rebuild with a different version/runtime, the only difference is that on AppImage application files and runtime files is separated
You can also bundle newer libs and run on old systems. But if the oldest version works perfectly why uses newer? This generally implies in more resource usage for things that is never used
If glibc is bundled, AppImage runs normally
flatpak/flatpak#3470 Of course you can test by yourself
NEWER versions (Debian Buster and Deepin 20 Beta), but during some time these distros was losed support, and backports isn't enabled by default
Do it one time. And the point was "AppImage doesn't have automatic app updates", this was wrong
Please conclude your argument
Flatpak is exactly it
Only works seamless under GNOME, by default is needed relogin for each app to show on menu, tested:
Since it is read only, it doesn't make any sense, this is a limitation |
|
Are you serious that you can't say good things about Flatpak without passing incorrect information in another format? You can say, for e.g:
|
|
The main trouble of Flatpak isn't with Flatpak itself, but on arguments used by who defends it as the best way to distribute applications |
|
👀 Looking at the current discussion, I think this is becoming ridiculous. There are @refi64 and @barthalion, who are both involved in Flatpak and doing really great work in developing Flatpak and Flathub on one side and @sudo-give-me-coffee on the other side who has his/her strong preference for appimages. But for both sides I have to say: I don't think this is the right fighting ground to figure out if the univeral truth is to use flatpak or appimage. Technically speaking, I would say both have their reason to exist and there is no clear winner for all users out there. So maybe writing books of arguments and accusing each other of stuff is not the right way to go about this at all. The decision has to be made by those who are willing to invest their time into maintaining these ways of software packaging. So maybe let the OBS developers decide? What I can tell so far is that I'm a heavy flatpak user and have the OBS version from FlatHub installed. It worked great out of the box, I was able to record all windows I wanted to record, GNOME did a proper indication that the screen was recorded and that basically means that the integration works as intended. Maybe that's something the developers can work with and I really hope, that this crusade can stop in here? How old are we? |
|
This is getting a little heated. There are some interesting points worth digging into. But lets not devolve to religious wars here. And please note this is not a page to figure out which platform is the one true platform. Simply to see how well they align with OBS and our goals. |
|
This was asked on Discord, and I thought it would be an interesting data point to share here as well. Here are the statistics from Flathub for com.obsproject.Studio:
It mixes from-scratch and delta downloads, so it's a bit hard to analyse it without doing some guess work, but the spikes seem to indicate that there are at least 6,000 computers installing and updating OBS Studio from Flathub in a single day. |
|
The only reason was the wrong information on #21 (comment) about AppImages They must Defend Flatpak without giving wrong information about another technology. If the incorrect information was about snaps, I would have done the same, even though I don't like the idea of snaps |
|
Most software centers are integrated (LinuxMint-mintinstall, Manjaro-pamac, GNOME Software, Discover on KDE, PopOS-appcenter....)
In the Steam from Flathub example, extensions (for OBS would be third-party plugins) for the user to conveniently add:
|
As a KDE Plasma user I can assure you, that it works perfectly there too! |
|
The reality here is that we don't have to choose between AppImage and Flatpak, we can do both. Also, the more of this can be automated in terms of building and making updates, the better. That reduces the number of things that might break or have to be upgraded between updates, and makes it so that people with less special knowledge can maintain it if need be. |
|
I was intrigued by @kkartaltepe's first comments (thanks for pointing those issues out!) and quickly investigated if it would be possible to build OBS Studio on Flatpak with support to Jack and ALSA. Turns out it's possible! Here's the updated manifest file. The usual rules apply: you need to have a functional Jack server in order to use the Jack plugin. |
|
And it needs flatpak 1.6.1 at least, at run time, to work. |
|
We'll lets test it out. Im unable to open file dialogs for the LUT video filter applied to a v4l2 source. Is this also happening on anyone elses flatpak (both the build instructions from the PR and the flathub package have this issue for me). building off the PR commit for both my local flatpak build and a non-flatpak version with no such issue. |
So, a bit of a philosophical question here: This is an RFC, so that typically implies that the implementation hasn't been done. Obviously, we can see a proof-of-concept already, but really the RFC discussion is intended to answer the question of "should we do this, and if so, how should it be done?" So in that sense, testing the POC might be outside the scope of the RFC, since the question is more about design than implementation quality. On the other hand, in order to make a determination of whether or not this will work for us, it's hard to say without testing something. Is it appropriate to test and iterate on a POC during an RFC? |
|
Well, ultimately, you are right. So as I'm sure you can see right above this comment, I've asked the maintainers for the current flatpak on flathub about plugin extension points. I'm glad I have obs-websockets working now, but I do want to use other plugins and we should figure out how to do it the right way. |
While discussing the Flatpak RFC [1], it was spotted that the LUT filter couldn't open the file selection dialog. It was explained, then, that the proper formats were either composed of "User Label (file extensions)", or "file extensions", and the LUT filter was setting "(file extensions)" without the actual user label. While this works on a standard Qt file selection dialog, it cannot be properly formatted as a set of D-Bus filters, thus breaking the sandbox integration. Add a simple user label to the LUT file filter. [1] obsproject/rfcs#21 (comment)
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
|
PR flathub/com.obsproject.Studio#80 makes the JACK plugin successfuly work on top of PipeWire. You still need to have PipeWire 0.3 installed on your host system. My personal expectation is that PipeWire 0.3 will be on most distros by next year (the biggest blocker was Debian, and I'm happy to say that the updated PipeWire package is getting close to land! See https://ftp-master.debian.org/new/pipewire_0.3.10-1.html and https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/3). I also expect the ALSA plugin to go through the same route, eventually. |
|
The've got 6 or so months to get through the process, I hope they can do it. |
|
I'm happy to report that |
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.yml file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.yml file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
Add a new com.obsproject.Studio.json file containing the dependencies and permissions required by OBS Studio. RFC: obsproject/rfcs#21
While discussing the Flatpak RFC [1], it was spotted that the LUT filter couldn't open the file selection dialog. It was explained, then, that the proper formats were either composed of "User Label (file extensions)", or "file extensions", and the LUT filter was setting "(file extensions)" without the actual user label. While this works on a standard Qt file selection dialog, it cannot be properly formatted as a set of D-Bus filters, thus breaking the sandbox integration. Add a simple user label to the LUT file filter. [1] obsproject/rfcs#21 (comment)
Summary
Flatpak is an app packaging and distribution mechanism widely available on Linux
distributions. To some distributions, Flatpak is part of the default experience.
Flatpak allows tighter control over the environment applications run in, how they
are packaged and installed, and also isolates the application from the host
system.
The goal is add support for Flatpak, both as a development platform, and also as
a distribution platform.
Motivation
As a complex multi-platform project, OBS Studio has a wide surface for breakage.
Bad packaging can be a real problem, given that many Linux distributions package
OBS Studio in slightly different and incompatible ways.
By supporting Flatpak, OBS Studio benefits from having a tight control over the
execution environment, and the packaging of plugins and dependencies. This will
reduce the number of moving part when running OBS Studio, which allows much easier
reproduction of bugs and, consequently, fixing them.
Internals
There are no code changes involved in adding Flatpak support. It is simply a
matter of adding a new file. This file is JSON formatted file containing the
dependencies, permissions, and the platform that OBS Studio depends on.
How We Teach This
Because this is an addition to the platform, users shouldn't be required to learn
about Flatpak. For developers, little will change.
Drawbacks
No known drawbacks.
Additional Information
Supporting Flatpak does not prevent OBS Studio from supporting other distribution
mechanisms, nor will affect Linux distributions that package OBS Studio manually.
Unresolved questions