Availability of old versions of a Flatpak at Flathub

I know that I can install old releases of a Flatpak at Flathub (and pin them).

I use some old version apps because I don’t like the changes made by developers. These are some apps that I use for work. So it is important to me to know if I can expect these old releases at Flathub will be available and working in the following year(s). (This is important to have a degree of confidence that new versions will not disrupt the workflow.)

Someone could tell me if is it reasonable to expect that old versions of a Flatpak at Flathub will be installable and usable by years?

For example, be able to install gedit 3.36.x Flatpak in 2022 …

There are no specific guarantees offered to users about the availability of old binary versions of a specific flatpak. Whilst there’s some older versions offered the ostree repo is regularly pruned of old versions. If you have a requirement for a specific older version of a flatpak that’s not available as a binary then I’d encourage you to check out its manifest from github and build it locally. Whilst we’re not quite able to make guarantees of absolute reproducibility of builds the flathub guidelines and the properties of flatpak mean that any user should be able to recreate any version they want with a couple of commands and a bit of CPU time (modulo the files in the manifest being available and any changes to runtimes etc.)

Flathub is a service offered to make the lives of Linux Application Developers easier and as such takes a slightly different point of view to other ways to get applications on Linux. We want to make sure that bug fixes from the developer are delivered to users and that they’re not reporting old fixed bugs again and again and that the configuration everyone uses is as similar as possible.

1 Like

I took some time to reproduce a build and it worked.

This leads me to another question:
The old versions of runtimes and SDK necessary to reproduce old builds are going to stay available or will they be pruned as the time goes by?

If they will be pruned too … could I build them from the manifesto like I did with the desired Flatpak?

The plan is to keep the old runtimes there as long as we can (forever?)

1 Like

In fact, we haven’t deleted anything since ~ 2019, and after recent migration to newer hardware we have plenty of space to continue doing so. At some point we will likely prune old application builds, but runtimes are here to stay forever.

1 Like

For what it’s worth, if you want to make a copy of an application along with all its dependencies to save somewhere you can use the flatpak create-usb command. The steps required to then install from the generated “USB” repository (which of course can be anywhere) differ depending on what version of Flatpak you’re using, but they’re documented in the man pages.

1 Like

I tried but I hit errors and didn’t push harder.

$ flatpak create-usb ./okular  org.kde.okular
error: Remote ‘flathub’ does not have a collection ID set, which is required for P2P distribution of ‘app/org.kde.okular/x86_64/stable’.

It seems to be related to https://github.com/flathub/flathub/issues/676. But I’m happy, by now, by the idea that I can build from manifests.

For the record you can set a collection ID on the flathub remote with flatpak remote-modify --collection-id=org.flathub.Stable flathub

Thanks. Now, it worked. But I don’t understand exactly what is this “collection ID” and the info that I find was very succinct (just touching this topic to explain a command, etc.).
But, is there any security or any other kind of consideration at leave this configured for Flathub (why this is not configured by default … anyway …)?

The collection ID is a way to uniquely identify things (apps, runtimes, appstream data, etc.) which is useful when distributing flatpaks offline (though it is also useful for using a local repo as a cache and still pulling some things from the Internet).

Setting it on the remote does affect the behavior of Flatpak. Before 1.7.1 it makes Flatpak check all mounted filesystems, and potentially also peers on the local network depending on the ostree version. GPG verification is used so there aren’t really security implications, except some DoS attacks if you’re not on a trusted network for example. After Flatpak 1.7.1 it makes Flatpak check repos configured by you or your system admin to sideload from, and depending on your linux distribution this may also include hot-plugged USB drives. But again GPG verification is used so you don’t have to trust the content on the drives.

As for why it’s not configured by default, it is because these features were experimental for some time. Probably collection IDs will be deployed at some point; as you point out there’s an issue open about that.

1 Like

Thanks for the crystal clear explanation!