Why is logseq not up to date in the AUR

Hi Guys, I’m using Logseq on Arch linux. I’ve downloaded it over the AUR, but I think the AUR is stuck in Version 9.9-1. If I update all packages it says, that there’s no update for logseq, but when I download the App Image it opens the same Logseq App I’ve installed, but now on the up to Date version (think it’s 9.11).
Can anyone help me ?

2 Likes

Hi, is there a particular reason for using Logseq from AUR?

AUR is a repository of user-submitted packages that can modify your system and it is great for that purpose.

Logseq is a third-party app and you don’t need to modify your system to include it, you can just use Logseq as a Flatpak app. Flatpak is how a Linux distro can be a platform for third party apps. I.e. apps from third party are plugged into your system without modifying it and mess with dependencies.

Some people like to use AUR when it doesn’t really make sense, so they introduce packages for third party apps. Sometimes these packages just download the binaries already built by the app devs (maybe from GitHub releases section) and add them to your system, using statically linked libraries and this is the case for Logseq too IIRC. If you are not sharing libraries it doesn’t make sense to modify your system like that.

What I am saying it that when it comes to Logseq, AUR is just doing what Flatpak would but brutally copying the whole app and the libraries it uses in your system in form of binaries. Flatpak instead keep apps separated from your system and the apps share as much libraries as possible. This is the case with Logseq Flatpak package too.

Since these people insisting in using AUR like that are few, packages like the above often are unmaintained and not updated.

For me Logseq not being updated in AUR is a good sign: it seems people are starting to understand AUR is not for that.

3 Likes

There are several AUR packages for Logseq. Each is slightly different. logseq-desktop-git is up to date (currently at 0.9.11).

The -git suffix indicates it is build from Git development branch, not an official release. This is not a slighty difference.

1 Like

Well, the aur install takes less space and is more transparent. Nevertheless, it is true that they take a couple of days to update because it is done by a third party.

It should be the opposite: the Flatpak version shares Electron and other stuff with other apps, while the AUR -bin version doesn’t. How did you measure the used space?

Notice that with some file systems / tools you don’t get the actual size of Flatpak apps and runtimes because they “don’t see” OSTree deduplication:

https://blogs.gnome.org/alexl/2017/10/02/on-application-sizes-and-bloat-in-flatpak/

Indeed, one of the main selling point of Flatpak is being able to have multiple libraries installed without duplicating the used storage :slightly_smiling_face:

1 Like

Oh, it was just because of the runtime. It’s true that if I install more packages using flatpack the “size per package” will be smaller!

Yes, while with AUR’s “-bin” packages you have a copy of Chromiun/Node/Electron for every Electron-based app you install.

If the problem is the duplication of files between Flatpak runtimes and the OS: in the future, using ComposeFS, the files will be shared between the OS, Flatpak and Podman containers, while keeping all the advantages of these technologies.

1 Like

Little aside here that Arch offers a system-wide electron install that can be used if the AUR maintainer is up to reading the documentation.

More work just to make Logseq more prone to bugs because the Electron version wouldn’t match the upstream one the devs test against… why bothering since Flatpak offers this out of the box?

Flatpak is literally a dream that came true: apps use the exact libraries they are supposed to use but multiple versions of the same libraries share as much bytes as possible.

2 Likes