-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for installing AppImages on Linux #15808
Comments
Do you mean integrate I’m not sure I understand the benefit of Homebrew distributing GUI apps in Linux, since that’s what |
With flatpak in particular, I suppose it's redundant, seeing as
While I concur that The request (or general inquiry about) availability of Casks on Linux has come up before:
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. |
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?
I'm not sure why we'd need to pick only one. Seems like implementing one will open a door to the others.
I'd go further than that: app images should be implemented as casks using the cask DSL and installed using cask code. |
True. I was mainly wondering what would justify the effort.
Good point. I also initially found it a bit confusing that I couldn’t just |
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:
|
This is exciting! Some thoughts:
|
Thanks everyone for the feedback. I am playing around some more with AppImages. It looks like most recent AppImages depend on Homebrew ships this as
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 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 |
Not necessarily. Does this issue get fixed via Of course, this would cause issues if someone wanted to also have 3.x in their system, but we can worry about that later.
How feasible would it be to modify the default
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.
I think this is 100% fine (for now). I don’t anticipate major design changes when switching off assuming the system has a functional |
@alebcay Is there any plans for these to be able to run with libfuse3 at some point?
A shim or
Note we already do this for
Nah, not a nice user experience.
This might be worth exploring?
@osalbahr Again, nah, this is an even worse user experience.
If you're not familiar: please don't say things should be trivial. |
Yes, upstream issue at AppImage/AppImageKit#1120. Looks like other packagers/downstreams have some similar concerns. |
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 |
Yes. This seems like it would be a useful addition to Homebrew, fits with the Cask metaphor and would be more useful than harmful. |
So this feature would automate installation of already automated software but not automate installation of currently non-automated software ? |
@KaKi87 I don't understand the question. |
There is software that is already installable automatically (i.e. using commands such as 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. |
Here are examples of software that currently doesn't have automation : GitHub Desktop, CopyQ, PeaZip, Tenacity, cortile, KeeWeb, Free Download Manager, Discord. |
This would likely/ideally/eventually be support for both types. |
All of these but Cortile (which has 60 stars) and KeeWeb are on Flathub. |
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 :
Thanks |
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. |
Hello, just found this issue. |
Not currently. |
To increase the security of AppImages, unofficial sandbox for them can be utilized: |
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 :) |
Verification
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.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-based1 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?
chmod
to make it executable, then just run it)..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.flatpak install flathub org.mozilla.firefox
. The adoption for flatpak is currently wider than that of snaps.The text was updated successfully, but these errors were encountered: