How to address fuse3 and fuse conflicts

bksubhuti · February 5, 2023, 4:45pm

I had an complaint made on our product recently that there is a conflict with 22.04 and older buntus because of fuse3 and fuse. They say that apt can handle this, but there are problems.

probono · February 19, 2023, 9:42am

sudo apt-get -y install libfuse2

or use the static AppImage, see Statically linked runtime · Issue #877 · AppImage/AppImageKit · GitHub on that. E.g., GitHub - probonopd/go-appimage: Go implementation of AppImage tools. Still experimental appimagetool uses that.

bksubhuti · June 18, 2023, 4:10pm

Fuse is a big problem and crashing people’s Ubuntu systems because installing fuse installs fuse3.

To fix this, I build the AppImage and then I extract it with --appimage-extract.
Then I rename the extracted stuff and then zip and ship that.

The user can then just unzip and click. No need permissions. no need fuse. No need anything. It just works!

However, I’m interested in the static AppImage.
I’ll try to figure out the links you sent me.
Our app also needs libsqlite3-dev It would be good if I could include that in the shipped product as well. How to do that?

Can you maybe make idiot instructions for me and others?
What would be the command to type and download.

Currently I use these commands in my build scrip on DigitalOcean

# Download the AppImage tool
wget https://github.com/AppImage/AppImageKit/releases/download/13/appimagetool-x86_64.AppImage

chmod +x appimagetool-x86_64.AppImage

# Build the AppImage
ARCH=x86_64 ./appimagetool-x86_64.AppImage TipitakaPaliReader.AppDir/ tipitaka_pali_reader.AppImage

probono · June 18, 2023, 6:21pm

appimagetool will use the static runtime by default soon:

github.com/AppImage/AppImageKit

Statically linked runtime

opened 11:08PM - 26 Oct 18 UTC

agowa

AppImages should run on all Linux Platforms, but currently they don't, this is b…ecause it is dynamically linked against glibc. I tried to run a AppImage on Alpine Linux and it failed because Alpine Linux is build around musl libc instead. I think AppImages should generally include all necessary dependencies and not some of them. Also adding libc would not increase the resulting size much, depending on the used libc, it may only be from 185k to 8M [libc Comparison Chart](http://www.etalabs.net/compare_libcs.html). And if the binary is also stripped it can also be a much less. AppImage should do something like this: 1. When creating, check the required symbols of the application and determine the smallest fitting libc to include. 2. Always produce statically linked binaries, that don't depend on anything on the system. 3. Recommend using musl libc instead of glibc, for various reasons like License (MIT ./. LGPL), binary size (527k ./. 8M).