Will you support at some point AppImage/Deb/RPM binaries on the downloads section?

[Koratsuki]

Will you support at some point AppImage/DEB/RPM binaries on the downloads section?

Is this possible in the near future?

Thanks in advance! 😎👍

[PietJanHein]

I would also like either AppImage or just an ordinary package. Flatpak (also Snap, even worse) is not an option for me, I dislike the system: lot of storage space used as soon as you use 1 (concrete example: over 1 GB for OBS-studio) and quite a clumsy system. An AppImage doesn't need so much storage if you just use 1 and it is as simple as downloading it and running the 'file'. I prefer an ordinary package but if you want 1 distroagnostic solution then I prefer AppImage.

[timur-g]

Let us keep this for AppImage to see if feasible. Snap is also possible. DEB/RMP not planned.

[G-i-o]

I also support AppImage as a slimmer alternative to Flatpaks which are indeed quite bulkier, not as portable and more cumbersome to manage in general....IMHO.

[sounddrill31]

I was working on a simple AppImage package for Collabora but I am stuck with one small thing 😢

It should be a small (hopefully) MUSL friendly AppImage that works across most modern linux distros. Also, If this works, you will see a single package ranging around just 160 to 210 MB! Which is, on any bright, sunny day, way smaller than the flatpak file provided.

(For more information on these special AppImages, please read https://github.com/pkgforge-dev/Anylinux-AppImages)

The problem is that for some reason, the WebView seems to be targeting the source directory which is something like file:///__w/CollaboraOffice-AppImage/CollaboraOffice-AppImage for me. Overriding the prefix in the configure script's arguments has no effect. I could be very wrong about this but maybe the flatpak installs it to a container friendly directory on the build system.

https://github.com/CollaboraOnline/online/blob/3867db1967c0ec719f9abebb8184442eb7dff09e/qt/WebView.cpp#L471-L474

My workflow repo: https://github.com/sounddrill31/CollaboraOffice-AppImage

Problem is, these AppImages are mounted to a directory like /tmp/.mount_CODA-remp5909683875341386346 which does not match the CI's source directories. I could probably just use a /app like flatpak json did at https://github.com/CollaboraOnline/online/blob/3867db1967c0ec719f9abebb8184442eb7dff09e/qt/flatpak/com.collabora.Office.json#L826-L829

I'd appreciate any help, guidance, advice, criticism and so on send my way for this!

js: Not allowed to load local resource: file:///__w/CollaboraOffice-AppImage/CollaboraOffice-AppImage/CODA/browser/dist/cool.html?starterMode=true&darkTheme=true

[sounddrill31]

I have an update. It works if I run a link during runtime to the tmp directory representing where I built this. https://github.com/sounddrill31/CollaboraOffice-AppImage/blob/e0d6277bf43fba0aba507544944405b8b1a5b204/make-appimage.sh#L30-L31

I hate this hack, but it works for now (till it's fixed upstream). This will need to be fixed soon, if there are any plans to do anything that's not a flatpak. (no idea about snaps)

Right now the AppImage is 500-ish MB, I will work on compressing it better when I get up tomorrow, getting it closer to the flatpak.

The size, when unpacked, is roughly the same, especially when you consider that here you don't need to download flatpak. Is it safe to drop core/include? As @Samueru-sama mentioned in this, it seem to work fine otherwise though that'll need more testing from my end.

https://github.com/sounddrill31/CollaboraOffice-AppImage/pull/2

[Samueru-sama]

Alright to resume some of the current issues:

• The app ends up being hardcoded to the browser and core repos when built, we were able to work around this issue by building in /tmp and then making a symlink at runtime. But yeah this means this applications will likely be never packaged as a deb or rpm when it gets hardcoded to look into its build directory. There isn't even an AUR package of this app and the reason is likely this.

• The core/instdir is massive on our end, I think this is the equivalent of the collaboraoffice dir in the flatpak, however there are big differences in the files and sizes:

• On our build we have to ship a 448 MiB extensions directory that just contains dictionaries. Removing that dir breaks languages in the app.

The flatpak doesn't have such dictionaries in it, I even installed the flatpak just in case they were downloaded at runtime and I can't find any. No idea how you are avoiding to ship all the dictionaries.

We also have 184 MiB of fonts in our fonts dir while the flatpak ships a third of that.