Collabora Office and Linux: More Distributions than Flatpak :D

Good morning everyone,

Do we have any interest towards non-flatpak containers or bundled package formats? Would people be willing to use them, once they are functional?


When working on AppImages, I also noticed a big issue that could potentially make the life of any package maintainer hell: CollaboraOnline/online/blob/3867db1967c0ec719f9abebb8184442eb7dff09e/qt/WebView.cpp#L471-L474

Poco::Path coolHtmlPath(getTopSrcDir(TOPSRCDIR));
coolHtmlPath.append("/browser/dist/cool.html");
Poco::URI urlAndQuery(coolHtmlPath);
urlAndQuery.setScheme("file");

This seems to be building the URL from the source directory. Is this a problem? Yes. It depends on the directories from core(the package in releases) and the built directory containing cool.html. The problem is that the source path on the CI rarely matches the end user’s system, except in flatpak lol (because of this, the issue is completely sidestepped over there). I believe this will definitely need to be fixed before working on other package types so package maintainers do not need to commit sacrilege as I have done.

I also plan to reproduce this issue better/more reliably soon and maybe open an issue in the repository when I get a little more time :smiley:


Here’s my work so far:

(Please consider the following a work in progress, made in spare time :smiley: )

As an experiment, I managed to package the built binary as an AppImage, with some path hacks to account for the above, and got an initial boot so far. The file is currently massive, a lot bigger than flatpak when both are compressed but that is something I will optimize later. https://github.com/sounddrill31/CollaboraOffice-AppImage/releases

(Uncompressed/installed/mounted → roughly the same size)

AppImages used to have a terrible reputation for compatibility especially due to conflicts between expectations, certain fuse packages on the end user’s system and the dependence on GLIBC.

This is not the situation today: Thanks to the Pkgforge community and AnyLinux AppImages, we don’t need to worry about any of that, as we use sharun to package relevant dependencies into a single package, including glibc. This may sound like a lot, but it’s usually way better than using flatpak.

If you’re curious on making your own AppImages and want to learn more about how the Pkgforge community overcame this, check out this page: Anylinux AppImages | Anylinux-AppImages

hi @sounddrill31

Thanks for the note. I see there is already discussion going on in GH Will you support at some point AppImage/Deb/RPM binaries on the downloads section? · Issue #13600 · CollaboraOnline/online · GitHub

So closing this topic on forum for now

Thanks
Darshan