search

HandBrake / HandBrake

HandBrake's main development repository
https://handbrake.fr
Other
17.93k stars 1.35k forks source link

Please provide an AppImage for Linux #1722

Open probonopd opened 5 years ago

probonopd commented 5 years ago

Describe the change or feature you'd like to see added to HandBrake:

Providing an AppImage would have, among others, these advantages:

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

What version of HandBrake are you currently using? (e.g., 1.0.0)

None, because there is no AppImage that I could run on my Live ISO system.

What operating system and version are you running? (e.g., Ubuntu 16.04 LTS, macOS 10.3 High Sierra, Windows 10 Creators Update)

Various Linux Live ISOs

probonopd commented 5 years ago

Here is an example of a video editor packaged as AppImage:

https://github.com/mltframework/shotcut/releases

Please let me know if you are interested, then I can look into sending a PR that will compile this application on Travis CI upon each git push, and upload an AppImage to https://github.com/HandBrake/HandBrake/releases.

sr55 commented 5 years ago

I think the same reply from #1702 pretty much applies here as well.

probonopd commented 5 years ago

In fact, AppImage is specifically designed to solve https://github.com/HandBrake/HandBrake/issues/1702#issuecomment-442516641

make the application runnable across multiple distributions using a single package. If I had to produce a separate package for every distribution because "it is native to X" and therefore better in some mysterious way we would be right back where we started having to produce different packages for every distribution.

Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others), and unlike with solutions like Flatpak or Snappy one does not need to install a Flatpak or Snappy runtime first. It "just works".

sr55 commented 5 years ago

We'll see what happens in the next year or two and we can see which platforms end up on top then decide what to support.

probonopd commented 5 years ago

Check this.

jstebbins commented 5 years ago

Thanks for the link. That's useful information. Although "search interest" doesn't necessarily equate with actual real world usage. Unfortunately, there are now several "one image to rule them all" implementations, which is just frustrating. The whole point is to produce one image. Not AppImage, Flatpak, Snap, docker, ... (there are more).

As I said in the other thread, my intention is to wait a while and see what settles out. For now, the official "one image" HandBrake solution is Flatpak. I'll do one or maybe two other "one image" alternative bundles when it's clear which are the most highly adopted across multiple distributions.

probonopd commented 5 years ago

The point is, AppImages do not have to be adopted by distributions. Only by authors and users. it is specifically designed this way because distributions will likely never agree on anything.

tradewatcher commented 5 years ago

Hi, I hope you offer an AppImage asap its the best solution of all.

I started with ppa.. took a look on snap and now praise AppImage (as Linux Beginner)

https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others

ghost commented 5 years ago

I second this notion. It would be nice to have the application available as an AppImage for all of the reasons outlined by the industrious soul Mr Peter.

pruebahola commented 3 years ago

Appimage is the perfect way to share software Please!

ssokolow commented 3 years ago

As a data point, I have to say that, if the only options were an up-to-date Appimage and a somewhat stale distro package, I'd choose the distro package.

Until I discovered HandBrake was on Flathub, I was on the 1.3.1 package from the Ubuntu mainline repositories and had no problem with it. I switched to the Flatpak because I get to keep the unified update and add some sandboxing that I can easily narrow down further using Flatseal.

(I'm on Kubuntu and Flatpak plugs nicely into Discover to merge pending Flatpak updates and pending APT updates into a single list.)

Appimages are basically the non-Store Windows model brought to Linux. It's up to the packager to make sure all the dependencies are bundled. It's up to the packager to provide for automatic updates. There's no unified "updates are done in privileged code run outside the sandbox" system. etc.

probonopd commented 3 years ago

Appimages are basically the non-Store Windows model brought to Linux

Exactly. They are like Portable Apps on Windows, where you don't need a system administrator and don't need to change anything in the system just to run an application. Not everyone has root rights!

ssokolow commented 3 years ago

Exactly. They are like Portable Apps on Windows, where you don't need a system administrator and don't need to change anything in the system just to run an application. Not everyone has root rights!

My point is that, for those of us who have any alternative, they're the worst possible option, only one step above "The administrator provided GCC, so I'll compile it and all its dependencies from source using --prefix=$HOME/opt" for maintainability.

...and they're so "mechanism over policy" (i.e. We're giving you all the pieces. Invent what you prefer.) that, for maintainers, they're a pain to support unless you can track down someone who has built a higer-level solution with AppImage as the underlying technology, which handles identifying necessary-to-bundle dependencies as reliably as the build tooling for Flatpak or Steam runtimes.

(DISCLAIMER: I checked that a few years ago, so they may have improved on that particular point.)

Not to mention, if you don't want more inconvenience, you have to make a conscious decision that you're using AppImage as an equivalent to Portable Apps and, as such, don't take responsibility for reinventing automatic update checking above and beyond anything you already cooked up for your Windows releases.

Sure, it's good to have a portable build, but make sure it's specifically for that purpose and don't try to let its purpose overlap with any of the other available distribution channels.

This line from the AppImage website is OK:

"As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application."

...but this line very much misleads developers on what they're getting and how it'll be received by downstream users:

"As an application author, I want to provide packages for Linux desktop systems, without the need to get it 'into' a distribution and without having to build for gazillions of different distributions."

Once Canonical accepts that their PR push failed on other distros and gives up on snappy like with Mir and upstart, Flatpak will be a better fit for that latter description in any case except "Portable Apps for Linux", since AppImage can't integrate with the desktop infrastructure in the way users have come to expect without preinstalled helpers equivalent to Flatpak or snappy or APT.

...and no, you can't just have each AppImage offer to automatically install the helpers. That'd go over as well as Google designing Chrome's install package to add a new APT repository for you. An individual upstream-provided package modifying the system at large should not become normalized. We don't need to reinvent the need for UAC.

Plus, these lines are definitely spin-doctored...

Easy.

The key idea of the AppImage format is one app = one file. Every AppImage contains an app and all the files the app needs to run. In other words, each AppImage has no dependencies other than what is included in the targeted base operating system(s).

...until you want to make sure you're up-to-date on things like security. Then either the developers have to reinvent updating (probably in the Windows "manually re-run the installer" way rather than just clicking one "Update" button for all apps and typing your password like with a unified system updater.) or the user has to manually poll for updates.

Either is the opposite of easier.

Trusted.

AppImage format is ideal for upstream packaging, which means that you get the software directly from the original author(s) without any intermediaries, exactly in the way the author(s) intended. And quickly.

That's not how I define trusted. I define "trusted" in a way that rules out PPAs and AppImage because neither a maintainer for the Debian or Ubuntu package repository nor Flatpak's sandbox are acting as a line of defense against upstream turning shady as happened to Audacity and various Firefox addons (eg. Stylish).

Again, that makes AppImage the opposite of trusted from the direction I look at it.

Fast.

AppImages can be downloaded and run without installation or the need for root rights.

I'm more concerned about the penalty incurred every time the program starts, similar to snappy, because it doesn't unpack the bundle to regular files once on install/update the way Flatpak or a traditional package manager would.

Again, the opposite of what they claim.

...also:

Check this.

Thanks for the link. That's useful information. Although "search interest" doesn't necessarily equate with actual real world usage.

Unless my experience was the extreme exception, a non-trivial portion of those are probably "I've heard of Snappy and Flatpak without having to actively seek out information, but what the heck is AppImage?"

ivan-hc commented 2 years ago

I have built an AppImage from PPA that should work on Ubuntu 18.04 or higher

https://github.com/ivan-hc/Handbrake-appimage/releases/tag/continuous

this repository uses github actions. I hope this works for you too (hoping for an official release).

secretmango commented 1 year ago

Flatpaks are to be preferred over Appimages. They are on a secure repository, saving the user all pgp verifications / security dangers. They also can auto-update easily and integrate into the system.

Literally the only appliance for Appimages is the use in the persistent volume in Tails, but this is pretty nieche and I guess you can also premanently install .deb apps somehow on Tails. On all other immuteable systems Flatpak should be preferred.

probonopd commented 1 year ago

Please discuss other formats elsewhere; this ticket is about AppImage which has its own set of advantages.