One of the features in the recent flatpak relase is described as:
Applications can now list a set of URIs that will be downloaded with the application
This seems a bit weird. Downloading an application already means your loading data from a URI. What is the usecase for this?
Normally all the data that is needed for your application will be bundled with it and this feature is not needed. However, in some cases applications are freely downloadable, but not redistributable. This only affects non-free software, but Flatpak wants to support both free and non-free software for pragmatic reasons.
Common examples of this are Spotify and Skype. I hope that they eventually will be available as native flatpaks, but in order to bootstrap the flatpak ecosystem we want to make it possible to distribute these right now.
So, how does this work? Lets take Spotify as an example. It is available as a binary debian package. I’ve created a wrapper application for it which contains all the dependencies it needs. It also specifies the URL of the debian package and its sha256 checksum, plus a script to unpack it.
When the user downloads the application it also downloads the deb, and then (in a sandbox) it runs the unpack script which extracts it and puts the files in the right place. Only then is the installation considered done, and from thereon it is used read-only.
I put up a build of the spotify app on S3, so to install spotify all you need to do is:
flatpak install --from https://s3.amazonaws.com/alexlarsson/spotify-repo/spotify.flatpakref
(Note: This requires flatpak 0.6.13 and the remote with the freedesktop runtime configured)
Here is an example of installing spotify from scratch:
It’s time for me to rework my Minecraft Flatpak to make it distributable. 🙂 https://github.com/Kekun/flatpak-minecraft
I’ve always wanted to be able to install all the programs without care for dependencies, and uninstall these apps by simply deleting them, without having to worry about leaving residual files.
Now we have the flatpacks and other containers like snap. But they are too complicated to use for the regular user: remembering the command syntax and usually requiring to follow a tutorial with the installation steps. Even though I’d like to be wrong, I don’t think they’re ready for everybody until you just need a single, easy to remember command or better, one click install.
Nacho: We’ll get there.
I best liked the part where it said “25739072 days 4 hours 47 minutes 30 seconds remaining” right before finishing the download.
This is really great. As a Flatpak user I’d like to thank you for all the work you are doing in making it easier to use.
I have a question related to how Flatpak apps depend on runtimes, and how that is going to scale.
If I understand it correctly, each Flatpak app that you install depends on a specific branch of a runtime, so if I build an app using org.gnome.Platform 3.20 then it won’t work with 3.22 unless I rebuild it again. How do you see this evolving as more upstreams start distributing their apps with Flatpak?
If GNOME releases a different runtime each 6 months, and you have a number of upstreams that use GNOME runtimes for their apps, this can easily lead to a situation where App1 uses GNOME 3.20, App2 uses 3.22 and App3 3.24. Do you expect upstreams to update their apps to use the most recent runtime to migitate this problem, or are we going to end up with N different runtimes installed after a few years?
Alberto: Well, you can’t expect to be able to run old versions of applications against newer dependencies and always work. So, yes, there will be several runtimes in use. However, I think in practice you’ll see that there are two kinds of app, those that rev quickly and rely on new features, these are going to get constant updates that bump the requirements to newer runtimes. Then there are things that very rarely change, and rely on smaller, less feature-full LTS runtimes. Such runtimes will have a longer lifetime and will not get a lot of new releases.
So, in practice I think there will be a lot of *possible* runtimes, but not that many in use on any particular machine at one time.
whether the runtimes can take care of their own glibc issues?
Say whether if i compile/build a flatpak app and runtime on Fedora 25+flatpak, and then can i make it in such a way that i can deploy it on Fedora 21 or debian 6 with old glibc etc ?
Of course, that is the whole point.
This is a revolution! I love that you care of proprietary apps too.
Awesome! Thanks a lot for the work put into Flatpak!
Fails with: “error: GPG signatures found, but none are in trusted keyring”
Fedora 25, first time I try to use Flatpack:
Required runtime for com.spotify.Client/x86_64/master (org.freedesktop.Platform/x86_64/1.4) is not installed, searching…
The required runtime org.freedesktop.Platform/x86_64/1.4 was not found in a configured remote.
error: The Application com.spotify.Client/x86_64/master requires the runtime org.freedesktop.Platform/x86_64/1.4 which is not installed
Not really clear how to proceed.
Daniel: If you run
first that should be fixed.
However, flatpak should have done that automatically. What flatpak version are you on?