Support for installing AppImages on Linux

[alebcay]

Verification

• [X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

Provide the ability to install applications packaged as AppImage format to be installed.

AppImages are similar (at least in user experience) to macOS .app bundles.

• Self-contained (application and any libraries)
• Relocatable
• Linux distro-agnostic
• Binary distribution provided by upstream
• Does not require root (no daemon etc. running in the background)

In the context of Homebrew, AppImages would be handled more like a cask than a formula.

Some upstreams may provide a direct AppImage. Others might not directly provide one, but it is also possible to create an AppImage out of an application's executable files. For instance, Firefox does not have an official AppImage but one can be created from the official upstream .tar.bz2 distribution (in this example, there's a community-maintained one too).

See https://appimage.github.io/ for a big collection of AppImages, some official and some unofficial.

What is the motivation for the feature?

Make it easier to install GUI-based¹ applications on Linux with Homebrew, similar to how one might install GUI-based applications with Homebrew Cask.

Originally requested/discussed at https://github.com/orgs/Homebrew/discussions/3789.

---

_{1. Yes, Homebrew Cask may distribute software that isn't strictly GUI-based, and some GUI-based applications on Linux can already be obtained as formulae. But we currently skip distributing some more complex desktop software (e.g. web browsers, music notation programs, media players) on Linux.}

How will the feature be relevant to at least 90% of Homebrew users?

This feature pertains only to Homebrew users on Linux. It would allow Linux users to obtain both CLI/libraries/other things from Homebrew formulae that they have today and also be able to obtain desktop applications, similar to what can be done with Homebrew Cask today for macOS users.

What alternatives to the feature have been considered?

• Nothing (the status quo). Users can always obtain AppImages by downloading it themselves. The installation process is trivial (chmod to make it executable, then just run it).
• Integrate with snaps instead. I would liken these more to .pkg installers on macOS or the App Store, they require root access to install, offer isolation/sandboxing, and are associated with a bundle ID. They are managed through a snap daemon (snapd), not directly manipulating the filesystem. The adoption for snap is, to my knowledge, spearheaded by Canonical and not nearly as prevalent as AppImage.
• Integrate with flatpak instead. These are similar in scope and role as snaps. They are similarly associated with a bundle ID and can be installed through a CLI, e.g. flatpak install flathub org.mozilla.firefox. The adoption for flatpak is currently wider than that of snaps.

[osalbahr]

Integrate with flatpak instead. These are similar in scope and role as snaps. They are similarly associated with a bundle ID and can be installed through a CLI, e.g. flatpak install flathub org.mozilla.firefox. The adoption for flatpak is currently wider than that of snaps.

Do you mean integrate brew with flatpak? How would that look like?

I’m not sure I understand the benefit of Homebrew distributing GUI apps in Linux, since that’s what flatpak is for.

[alebcay]

Do you mean integrate brew with flatpak? How would that look like?

With flatpak in particular, I suppose it's redundant, seeing as flatpak possesses package manager-like functionality.

I’m not sure I understand the benefit of Homebrew distributing GUI apps in Linux, since that’s what flatpak is for.

While I concur that flatpak does already exist (and works pretty well), I don't see any technical reason not to distribute GUI apps on Linux. Personally, I think that users might find it weird/confusing to figure out what is/isn't available via Homebrew on Linux. I recall that when snaps/flatpaks were introduced, even that was a bit confusing since people had to understand which places to install certain things from (where as previously one might have needed to add a PPA, for instance, but it was all through one set of tooling).

The request (or general inquiry about) availability of Casks on Linux has come up before:

• https://github.com/orgs/Homebrew/discussions/3789 (linked also in the original post)
• https://github.com/orgs/Homebrew/discussions/2808
• https://github.com/orgs/Homebrew/discussions/3999

Conversely, a more approachable idea is to implement this as an external command (as Homebrew Cask was initially, after all), and see if it gains traction.

In any case, I'll leave this open for now for further comments/feedback.

[MikeMcQuaid]

This seems like a good idea that will be a pretty heavy lift. Just for clarity @alebcay: are you suggesting this or also volunteering to implement?

• Integrate with snaps instead.
• Integrate with flatpak instead.

I'm not sure why we'd need to pick only one. Seems like implementing one will open a door to the others.

In the context of Homebrew, AppImages would be handled more like a cask than a formula.

I'd go further than that: app images should be implemented as casks using the cask DSL and installed using cask code.

[osalbahr]

While I concur that flatpak does already exist (and works pretty well), I don't see any technical reason not to distribute GUI apps on Linux.

True. I was mainly wondering what would justify the effort.

Personally, I think that users might find it weird/confusing to figure out what is/isn't available via Homebrew on Linux. I recall that when snaps/flatpaks were introduced, even that was a bit confusing since people had to understand which places to install certain things from (where as previously one might have needed to add a PPA, for instance, but it was all through one set of tooling).

Good point. I also initially found it a bit confusing that I couldn’t just flatpak install discord (for example) and always have to search for and type long name. And Flathub iirc is much more “open” meaning that I have to put in extra effort vetting individual packages (and flatpak isn’t unique in that regard). I really like that Homebrew takes the majority of the burden by having one repo I can trust and an easy mechanism to add taps i.e. third party repos.

[alebcay]

are you suggesting this or also volunteering to implement?

Yes, I'm interested in working on this. Haven't touched cask stuff as much in the past but would be interested in giving it a try.

I'd go further than that: app images should be implemented as casks using the cask DSL and installed using cask code.

👍

[MikeMcQuaid]

Yes, I'm interested in working on this. Haven't touched cask stuff as much in the past but would be interested in giving it a try.

Awesome, would love to see this.

Some design notes:

• Should probably gate this behind HOMEBREW_DEVELOPER or even HOMEBREW_CASK_ON_LINUX and keep it undocumented until we're ready for users to use it. This should allow incremental work via smaller PRs without needing to announce it until we're ready.
• Given Casks have been macOS only for a (very) long time: a Cask should be assumed to be macOS-only unless it has some sort of DSL set indicating it works (only) on Linux.
• May even want to consider another e.g. directory name rather than Casks e.g. Barrels or whatever so macOS-only and Linux-only casks can be easily distinguished without having to parse them fully

[rohanssrao]

This is exciting! Some thoughts:

• It would be very helpful to integrate installed AppImages with desktop environments by installing .desktop files somewhere (probably $XDG_DATA_HOME/applications, falling back to ~/.local/share/applications if that's undefined). AppImages come with .desktop files themselves (https://docs.appimage.org/reference/desktop-integration.html#desktop-files), and there seems to be a tool that could help with desktop integration: https://github.com/AppImageCommunity/appimaged. Otherwise, brew could extract the AppImage and look for the .desktop file itself, or there could be a GitHub Actions runner that does this, or something else. Icons for these files to reference may need to be organized in another directory.
• There is a large AppImage repository at https://github.com/AppImage/appimage.github.io. It could be used for the initial population of the Cask repo.

[alebcay]

Thanks everyone for the feedback. I am playing around some more with AppImages. It looks like most recent AppImages depend on libfuse2 to be present to operate (they mount the contents in order to be able to execute).

Homebrew ships this as libfuse@2. However, getting the AppImages to use the brewed libfuse@2 runs into a few obstacles:

• libfuse@2 is keg-only because libfuse is now on 3.x, so need to add brewed fusermount program to path
• Neither$(HOMEBREW_PREFIX)/lib nor $(HOMEBREW_PREFIX)/opt/libfuse@2/lib is in LD_LIBRARY_PATH by default, so the AppImage can't load libfuse.so.2 out of the box
• We don't set suid/guid bits on brewed fusermount program and this program is owned by the (potentially unprivileged) user instead of root, so when the AppImage attempts to run it has permission issues

For addressing the first two, we can try and provide some kind of a shim but maybe there's a nicer way to go about it. For the fusermount permissions, the naive way is to have brew prompt for sudo once when installing any AppImage for the first time to chown, chgrp, and set the suid/guid bits appropriately. But then brew will be unable to manage the keg anymore (can't delete/replace the root-owned files).

Alternatively, we can require the end user to install libfuse2 from their system package manager.

An alternative of last resort is to (1) pass a flag that extracts the AppImage fully before running which takes a hit on startup performance or (2) fully extract each AppImage out of its packaging, which removes the need for libfuse2 but is not the intended happy path for consuming AppImages.

[osalbahr]

• libfuse@2 is keg-only because libfuse is now on 3.x, so need to add brewed fusermount program to path

Not necessarily. Does this issue get fixed via brew link libfuse@2? We can ask users to run the link command.

Of course, this would cause issues if someone wanted to also have 3.x in their system, but we can worry about that later.

• Neither$(HOMEBREW_PREFIX)/lib nor $(HOMEBREW_PREFIX)/opt/libfuse@2/lib is in LD_LIBRARY_PATH by default, so the AppImage can't load libfuse.so.2 out of the box

How feasible would it be to modify the default LD_LIBRARY_PATH for the AppImage? I’m not familiar, but it seems like something that should be trivial. Automating it, though, might be more involved.

For the fusermount permissions, the naive way is to have brew prompt for sudo once when installing any AppImage for the first time to chown, chgrp, and set the suid/guid bits appropriately.

I think it’s better to ask users to manually add the permission themselves so they know what they’re doing (hopefully). And give them the command, similarly to how install.sh asks users to modify shell startup files. The install script does prompt sudo to change directory permissions, but it’s never to add suid/guid bits on behalf of the user.

Alternatively, we can require the end user to install libfuse2 from their system package manager.

I think this is 100% fine (for now). I don’t anticipate major design changes when switching off assuming the system has a functional libfuse2. We can also ask users to run the respective package manager’s command, just like how Homebrew expects git/curl to pre-exist on Linux even though they can be brewed but it avoids unnecessary complications.

[MikeMcQuaid]

It looks like most recent AppImages depend on libfuse2 to be present to operate (they mount the contents in order to be able to execute).

@alebcay Is there any plans for these to be able to run with libfuse3 at some point?

For addressing the first two, we can try and provide some kind of a shim but maybe there's a nicer way to go about it.

A shim or brew subcommand seems ideal.

For the fusermount permissions, the naive way is to have brew prompt for sudo once when installing any AppImage for the first time to chown, chgrp, and set the suid/guid bits appropriately. But then brew will be unable to manage the keg anymore (can't delete/replace the root-owned files).

Note we already do this for sudo brew services so there's an existing model for this.

Alternatively, we can require the end user to install libfuse2 from their system package manager.

Nah, not a nice user experience.

fully extract each AppImage out of its packaging, which removes the need for libfuse2 but is not the intended happy path for consuming AppImages.

This might be worth exploring?

Not necessarily. Does this issue get fixed via brew link libfuse@2? We can ask users to run the link command.

Alternatively, we can require the end user to install libfuse2 from their system package manager.

I think this is 100% fine (for now).

@osalbahr Again, nah, this is an even worse user experience.

I’m not familiar, but it seems like something that should be trivial.

If you're not familiar: please don't say things should be trivial.

[alebcay]

Is there any plans for these to be able to run with libfuse3 at some point?

Yes, upstream issue at https://github.com/AppImage/AppImageKit/issues/1120. Looks like other packagers/downstreams have some similar concerns.

[KaKi87]

Hi,

I believed that porting Homebrew to Linux was about allowing users to automate installing & upgrading applications that aren't available on any store, in which case integrating Flatpak or Snap, which are app stores, would be off-topic.

Was I wrong ?

Thanks

[MikeMcQuaid]

I believed that porting Homebrew to Linux was about allowing users to automate installing & upgrading applications that aren't available on any store, in which case integrating Flatpak or Snap, which are app stores, would be off-topic.

Was I wrong ?

Yes. This seems like it would be a useful addition to Homebrew, fits with the Cask metaphor and would be more useful than harmful.

[KaKi87]

So this feature would automate installation of already automated software but not automate installation of currently non-automated software ?

[MikeMcQuaid]

@KaKi87 I don't understand the question.

[KaKi87]

There is software that is already installable automatically (i.e. using commands such as flatpak add) and software that is not installable automatically (i.e. requires manually downloading the binary and creating a .desktop file).

Initially, I thought that this port's purpose would be to add support for the second kind, i.e. provide automation for software that currently doesn't have automation.

But, if I understand correctly, the purpose is to add support for the first kind, i.e. provide automation for software that already has automation.

[KaKi87]

Here are examples of software that currently doesn't have automation : GitHub Desktop, CopyQ, PeaZip, Tenacity, cortile, KeeWeb, Free Download Manager, Discord.

[MikeMcQuaid]

This would likely/ideally/eventually be support for both types.

[rohanssrao]

@KaKi87

Here are examples of software that currently doesn't have automation : GitHub Desktop, CopyQ, PeaZip, Tenacity, cortile, KeeWeb, Free Download Manager, Discord.

All of these but Cortile (which has 60 stars) and KeeWeb are on Flathub.

[KaKi87]

I'm sorry, you're right, turns out I didn't properly check whether these apps still don't have automation, only that they didn't have automation at the time I installed these, by looking into my Downloads directory. 😅

That said :

• CopyQ has theming issues due to Flatpak's sandboxing and therefore warrants DEB automation ;
• PeaZip has only been available since a few days ;
• Tenacity has issues due to Flatpak's sandboxing and therefore warrants DEB automation ;
• Free Download Manager isn't up to date on Flatpak and therefore warrants DEB automation ;
• Discord had limitations due to Flatpak's sandboxing and therefore warrants DEB automation.

Thanks

[KaKi87]

Additionally, here are new names that, this time, I checked properly : OnlyOffice (available but outdated on Flathub), scrcpy, LosslessCut (available but outdated on Flathub), DeaDBeeF, USBImager, TeamViewer.

[b3n-h4il]

Hello, just found this issue. Is there work being done? Maybe some pointers on the help needed?

[MikeMcQuaid]

Is there work being done?

Not currently.

[fiftydinar]

To increase the security of AppImages, unofficial sandbox for them can be utilized: https://github.com/mgord9518/aisap

[KaKi87]

Hi again,

A few months ago, I started developing a tool named dynapt to automatically fetch updates through APT for packages that don't provide an APT repository.

It also supports wrapping AppImage into DEBs so that these can be installed through APT as well, and the next step will be supporting bare binaries.

While it's experimental, I made a tutorial for using it here.

Feedback is welcome :)