Linux packaging: ship as flatpak on flathub

Basement
7

We will likely be able to build flatpaks once 1.0 releases.

Thanks for considering it. :slightly_smiling_face:

For now, I don’t think we will maintain presence on external hosting sites like Flathub or Snapcraft - there’s a fair amount of them (there’s also brew for MacOS and chocolatey for windows) and with our release frequency (1-2 release/week) it cuts into development time and complicates the release process.

I’m very much aware of this problem and would hate to let these mundane busy work getting in the way of actual development, but this is exactly why I suggested shipping the flatpak on flathub:

  • First of all, no developer account is required for publishing on flathub. Spending time and effort on maintaining presence is not necessary. All you need to do is submitting a pull request, and then do minimal metadata maintenance for new releases, as I’ll elaborate below with examples.
  • The basic steps of publishing a flatpak on flathub goes like this:
    1. Submit a pull request here: Pull requests · flathub/flathub · GitHub
    2. Make changes if needed and eventually a dedicated repository will be created
      • example: Zotero
      • The only change that I personally think would be beneficial is to disable built-in OTA by default in this flavor, so updates can be taken care of by flatpak instead. This will not force the user to re-download the static electron releases, because as I’ve mentioned in the main post before, flatpak has delta updates, so essentially this will retrieve a similar amount of data from the internet like a typical .asar-only OTA would.
    3. Flatpak bundles will be automatically built and distributed by flathub
  • The basic steps of maintaining this flatpak is also very easy. Suppose you have a .tar.gz or similar release on github, and you have an update to push, all you need to do is to push a commit to change the file hash, file URL and the version info in the metadata, and everything else will be taken care of by flathub. This commit from the Zotero flatpak repo is a very good example to showcase the amount of maintenance effort (or lack thereof :wink:) required: Update to Zotero 5.0.89 · flathub/org.zotero.Zotero@859fc9a · GitHub

As for automatic updates, we maintain our own update system which is much much optimal than what a platform updater can offer. This is because we only update the .asar files which is less than 5mb as of current latest version. We’ve only made a single full electron update from 8.2.5 to 10.1.1 (in obsidian v0.8.12), which unlocked additional functionality if you did the optional electron upgrade. This update is shipped to the user-preference folder ./config/obsidian/ which is outside of the AppImage already.

https://blogs.gnome.org/mclasen/2018/08/02/on-flatpak-updates/

Flatpak has feature-parity with your own OTA system.

  • Your OTA mechanism provides 2 main benefits: efficiency and stability. Flatpak can provide these benefits equally well, as I’ll address down below.
  • OTA is efficient because only the asar is ever updated, and technically flatpak can do this as well, just in a different way. Flatpak does delta updates, which essentially only downloads the asar anyway if the Electron base has not changed. Using flatpak does not imply the user must download the same Electron base over and over again. Most other packaging formats do not provide this feature, or are rather tedious to use/setup (i.e. RPM).
    • Note: as someone who is almost always on a slow and metered connection, I would not have recommended flatpak if it does not support delta updates.
  • OTA helps with stability because the new asar will only be used on the next startup, so nothing will be swapped out while the application is running. Typical Linux package managers have an awful habit of pulling the rug out under running applications if you choose to update something while it’s running, which causes a lot of stability issues. For example, firefox gets incredibly upset if you update itself or some important libs while it’s running. Flatpak does not do this, it will not only keep existing deployments around until the last user is gone, and it will also inform the application that it has been updated. Obsidian can simply look for /app/.updated and prompt the user to restart the application, if you decide to take advantage of this feature.

Totally understand the user experience though. I think for AppImage, you can use AppImageLauncher (https://github.com/TheAssassin/AppImageLauncher ) which is designed specifically to install AppImages with the .desktop files properly.

AppImageLauncher is only packaged on Ubuntu (as .deb). This has the same distribution lock-in effect as snap does. It’s true that anyone could install this from source or use the provided appimage to install, but do you really want to set this kind of complex prerequisite for your software to integrate well into people’s systems?

If Obsidian is shipped on flathub, most users with some kind of software store (gnome software for example) can install and update Obsidian with a single click, as long as flathub has been added as a repository on their systems. If not, flathub has detailed setup instructions for pretty much every single distribution now, which is typically one or two commands that just needs to be copy-pasted into the terminal.

We’ll think about building flatpaks. Right now I’m just really disappointed in the Linux ecosystem for being so fragmented.

As a Linux user, I’m equally disappointed as well, and there are good reasons why I did not ask about distribution packaging, debs and rpms. Thanks for your time, and I hope this reply can clarify some things for you. Please let me know if you have any other questions.

3 Likes