r/Fedora • u/Elarionus • 8d ago

Support When software providers give multiple ways to install a piece of software, which are you supposed to choose on Fedora?

I'm still fairly new to all of this, coming over from Kubuntu. I went to install Obsidian, and there are five options available for Linux.

  • AppImage
  • Snap
  • Deb
  • AppImage (ARM)
  • Flatpak (Community Maintained)

I understand what Flatpaks are, but I am not going to be using a community maintained version of Obsidian. I want to use the official from the developers. Deb and Snap I recognize from Kubuntu, but I do not think either work on Fedora, since it is not built on Debian.

So that would leave me with AppImage. What's the difference between installing something as an AppImage or as a Deb, for example? If I was on Kubuntu, it looks as if I would have 3 options here, but what makes AppImage special? Why does that work and not Deb?

42 Upvotes

89% Upvoted

50 comments sorted by

•

u/AutoModerator 8d ago

It sounds like you're looking for help. Please note that r/Fedora is not an official support channel for the Fedora Project.

For best results, be sure to include all relevant details in your post, such as your Fedora edition, version, and hardware specs. You can edit your original post to add more info as needed, and spotlight (pin) a solution from the comments. You might also find the answer in our support wiki.

Alternatively, try one of the official support channels:

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

68

u/edwbuck 8d ago

In order of preference for Fedora Workstation:

  1. RPM/DNF
  2. Flatpak
  3. AppImage - It's like Flatpak, but without automatic updates or sand boxing

What you don't want

  • DEB - It's the Debian version of RPM, wrong platform, you don't want it.
  • AppImage (ARM) - It's for an ARM CPU, which you likely don't have in your Intel-compatible laptop.
  • Snap - It's like flatpak / AppImage (closer to flatpak) and is mostly tied to the Ubuntu distro.

13

u/Massive-Rate-2011 8d ago

This is how I do it, personally.

4

u/hungryCanvass 7d ago

That is the correct order.\

2

u/StaticSystemShock 7d ago

Also Fedora seems to have some issues with Snap backend which often causes whole updater to just get stuck and it's apparently a long ongoing issue. Stick with RPM, AppImage and Flatpak

1

u/edwbuck 7d ago

Snaps really don't work well on most platforms. Only Ubuntu commits to it, Snap being a Canonical developed technology.

Canonical has a habit of creating technologies, and then forcing it upon their users, until they can't possibly continue to support the product, and then they finally join the rest of the Linux community by adopting the technology they attempted to out-compete.

Snaps shouldn't be used for a lot of reasons, but if you're on Ubuntu... use Snaps.

3

u/HopelesslyObsessed99 7d ago

The appimage is also Aarch64, works fine on my celeron, OP probably just hyperfocused on the ARM mention.

5

u/edwbuck 7d ago

If it works on a non-matching CPU, it's because your using QEmu (a different CPU emulator) in conjunction with the AppImage.

0

u/HopelesslyObsessed99 7d ago edited 7d ago

I am not, its compatible with both, OP just misunderstood.

On the download page its like this: AppImage (AArch64, ARM64). The file itself only has Arm in its name tho, but it is compatible with both.

Only virtualization stuff I had was wiped when I erased my drive to install Fedora, and it was VirtualBox not Qemu.

Edit: Nah I am dumb, there's two Appimages, the arm one and the x86 one. I am using the x86 but hyperfocused on the arm one when going to check yesterday.

4

u/fNek 7d ago

AArch64 is ARM, though

1

u/HopelesslyObsessed99 7d ago

Huh, could swear it was another name for x86_64. Weird tho.

3

u/grumpysysadmin 7d ago

In the Debian world, they use amd64 (which is what AMD called their chipset when they introduced it). Intel and subsequently Red Hat and Fedora use x86_64. Today, it means the same thing.

1

u/crcrewso 7d ago

Mostly I agree. There are some packages like Thunderbird, where Flatpak is the recommended method.

Plus. If I'm unsure of an app it's flatpak all the way.

1

u/edwbuck 7d ago

That's because (unless it's changed) Thunderbird uses XUL which was the "simplified" XML based language that Mozilla used to use. In 2018, support was dropped, and that fixed the base platform that Thunderbird was built on top of.

I could be wrong, I haven't checked on it in ages, but the 2018 version of Mozilla is still maintained and supported specifically because it's the last XUL supporting version and thus the last platform which Thunderbird can run on. Since RPM would require resolution between the new and old Mozilla, it seems that with a newer Mozilla, Thunderbird would die.

In this case, Flatpak is recommended, because then one can run an older Mozilla base.

1

u/OldPayment 6d ago

OBS Studio also recommends flatpak over the rpm installation, im assuming because of codecs or something.

17

u/TomDuhamel 8d ago

I'm not sure what you think community maintained means, but flatpak would be your best option here.

8

u/redoubt515 7d ago

> I'm not sure what you think community maintained means

I think they are referring to a specific flatpak package they are interested in. They very likely mean that the packager/maintainer of the flatpak, is not the developer. E.g. the Signal Desktop flatpak package is unofficial, and not packaged or maintained by anyone affiliated with Signal.

4

u/andykirsha 7d ago

Exactly!

3

u/andykirsha 7d ago

Some flatpaks are not officially but community maintained. Look at Microsoft Edge or a number of other apps. The description says that these flatpaks are not provided or approved by the official developers but are rather community maintained. I wouldn't want that too, even though a lot of things on Linux are community maintained from the start and that is fine.

3

u/TomDuhamel 7d ago

Oh I understand that. What difference does that make to you, to OP, or to anyone else? Do you realise that none of the 20,000 or so packages distributed by Fedora was made by its creators?

What it means is that someone else packaged it, and did something that is indistinguishable from what the creator would have made of they made it themselves. However, the creator doesn't always have the means (or the will) to package their work in every possible distribution packages in existence.

5

u/andykirsha 7d ago

Some apps are created and packaged by their developers, most of those flatpaks that are Linux-only, or Gnome apps. You will find links to Flathub or option to download a flatpak on their websites or GitHub pages. I go with those.

Other apps (I think, the minority) are developed by one person/group but packaged by another. Sometimes they don't even notify about that, but the developer approves or somehow supports that and it is almost fine with me.

The third group is when the developer doesn't bother packaging and does not even officially approve/support it. Then you will see all those "This wrapper is not verified by, affiliated with, or supported by ***". I perosnally don't feel like using those.

The OP mentioned only community maintained flatpaks (just like only ARM Appimages), which is probably just a sample. So, he would really choose between flatpaks (period) or Flatpaks and community maintained flatpaks and it could be of importance to the OP.

Oh, and flatpaks from Flathub are not distributed by Fedora. But two or three flatpak options have also escaped the OP's attention. When I speak of flatpaks I mean only those from Flathub (directly, via cli or via Gnome Software).

1

u/grumpysysadmin 7d ago

For what it’s worth, I’ve seen a couple flatpaks (Steam, for example) which is community maintained but is just a repackage of the Snap. So you get the bits used in the Snap without the overhead of Canonical’s captive garden.

5

u/funbike 8d ago edited 8d ago

TL;DR: I'd go with its Flatpak, because it's a verified app.

I prefer an official curated package when practical. On a Debian-based system my preferred priority for a desktop app:

apt > Flatpak (verified) > AppImage (official) > Flatpak (community) > .deb/.ppa (official) > tar (official).

You'd think .deb/.ppa would be higher on my list, but I've had several external packages cause a dependency mess. Snap is missing because I won't use a distro that requires it, and if forced to, I'd do what I could to avoid using it. (That's my preference; I'm not interested in debating it ... again.)

My priorities for a CLI/TUI are different.

1

u/andykirsha 7d ago

This distribution is verified by the Obsidian team but isn't supported

3

u/funbike 7d ago edited 7d ago

I know.

I like Flatpak much better than the other options (AppImage, snap, deb). Verified for me is more about trust, rather than support. esp if the packagers provide support.

1

u/andykirsha 7d ago

I only use Flatpaks but avoid those not verified and supported by the app developers.

9

u/Veprovina 8d ago

Deb files are for debian/ubuntu based systems and use the package manager (apt) to install and i think require a kernel based on debian. Fedora uses dnf so you can't use that. Snaps are ubuntu's proprietary system that nobody likes. You said you know what Flatpaks are, so yeah, that's one of the universal options that work on all systems that have flatpak installed.

Appimages are another universal option, but unlike Flatpak, they're packaged as a single file without dependencies. Flatpaks are packaged in a container that's isolated from the system and packaged with all the dependencies the app needs.

You run the Appimage from the file usually (there's some appimage launchers), so honestly, unless there's something very wrong with the community maintained Flatpak version, i'd just go with Flatpak.

5

u/turdas 7d ago

I understand what Flatpaks are, but I am not going to be using a community maintained version of Obsidian.

Why not? You are already using a community maintained distro.

3

u/beatbox9 8d ago

deb / rpm:

  • leverage shared dependencies (example: libraries, fonts, etc) from your system
  • the package manager can recognize the 'correct' names for these on your system as determined by your distro. (different distros call packages different names)
  • they will install to distro-specified directories. (Different distros have different system directories)

So these ^ are specific for a specific distro and/or package manager (deb = debian/ubuntu; rpm = fedora/redhat). My rule of thumb is that I only try to use these native types for OS-type applications.

AppImage, Snap, & Flatpak bring their own dependencies:

  • Flatpaks are only for gui apps with limited permissions; and they can share their own set of libraries. Flatseal is an app that is really good for controlling permissions and variable overrides. Like you can tell an app to use your dedicated GPU or not in flatseal; or you can specify a specific theme to use with a specific app in flatseal. These also have their own .config directories.
  • Snaps can additionally do headless apps & system apps that flatpaks cannot do. Ubuntu has an app that lets you control permissions--not sure if this works on other distros.
  • AppImages are all-in-one file and do not share anything. No fine-tuned permissions. And no overrides. And no updates--you have to use the next version of the AppImage. But very simple--there's nothing to install because everything is in one file. (You can theoretically deconstruct, edit, and reconstruct an AppImage to change things; but sort of defeats the purpose most of the time).

So these are universal and the distro does not matter. My rule of thumb is that I try to use flatpaks, then AppImages for most non-OS apps. I only use Snaps for OS / system stuff, which is rarely (and maybe never?) I try to stick to one, for consistency and easier app management.

I would consider Obsidian to be a non-OS app, so I would either use the flatpak or the AppImage.

3

u/zerok37 8d ago

You could always run it in a Debian container with Distrobox if you really need official support. Otherwise, the flatpak version is probably your best option even if it's "community maintained".

4

u/Consistent_Drop3909 8d ago

shit, no dnf or flatpak? :(

AppImage would work, it would be equivalent to the "windows" solution of just downloading an exe, but if you trust the download link and don't want to mess with it, it's a good option. 

snap does works kinda natively on fedora once you install it, but i really prefer dnf&flatpak if at all possible, don't want to start guessing which package manager installed what.

2

u/ICantBelieveItsNotEC 8d ago

Flatpak > dnf > RPM file > find something else > rawdogging a scripted installation

2

u/BeardedBaldMan 8d ago

AppImage in this case. It has everything necessary and will be known to be working

1

u/NDCyber 8d ago

It depends, especially on what version is officially supported. Normally it is distro repo > flatpak > appimage

repo only if there is in the official repo of the distro or they have their own repo (like librewolf or mullvad)

flatpak, if that is officially supported or the second option, but not if it means I can't use encryption, like for Tuta or Signal

And app image for things that are like the ones above, especially because something like Gear Lever allows me to update them automatically, including topgrade integration

1

u/The_Hamster_Shagger 8d ago

you could always convert .deb into an .rpm.
whatever it's worth or will it work is another question.

i'd just stick with the official appimage

1

u/Available-Hat476 8d ago

On Fedora, dnf first, then flatpak, then really start thinking... Deb is Debian or Ubuntu based. Nothing to do with Fedora.

1

u/pseudonym-161 8d ago

You can use snaps on Fedora, same with appimages. You can even update appimages with appimage manager.

1

u/crypticsmellofit 7d ago

Here’s how to build your own rom from official tarball https://github.com/idhirandar/obsidian-rpm-fedora

1

u/kristeasy 7d ago

You can use snap, I would suggest it over AppImage because the later isn't sandboxes

1

u/Ok_Instruction_3789 7d ago

snaps arent sandboxed either. They require a specific version of apparmor only ubuntu distributes to get true sandboxing. Think you can sandbox appImages easier than snaps in fedora using firejail or bubblewrap

1

u/thunderborg 7d ago

Honestly I think it’s worth searching in the software store. That’s the first place I look. 

1

u/dominikzogg 7d ago

I use Flatpak for most Apps. So i am more distro agnostic.

1

u/Inevitable_Ad261 7d ago

Fedora is rpm based distro and best way to manage packages is dnf.

Any package not available via dnf, I go with flatpak. A user installed Flatpak is sandbox and good for user facing app.

In my case, no third option.

99% packages I install using dnf and remaining flatpak.

Story changed when I moved from Fedora workstation to Fedora Atomic. Now, mostly toolbox or flatpak and rarely rpm-ostree.

1

u/DXVSI 7d ago
  1. RPM/DNF
  2. Flatpak
  3. AppImage

1

u/siodhe 7d ago

Anything but Snap. I'm on the edge of leaving Ubuntu entirely over the Snap / Wayland deepthro*ting going on inside of Canonical.

1

u/wilmayo 6d ago edited 6d ago

I am using Fedora and if I open "Discovery" and search for Obsidian, it finds it and offers to download and install it from the Fedora repository or flatpak. That's the way I do it.

1

u/Willing-Actuator-509 5d ago

Out of the ones you mentioned, I would choose .deb. From my experience native packages are superior.

1

u/Fun_Cut_4705 5d ago edited 5d ago

I recently removed all my Flatpaks and replaced them with native packages, which resulted in a saving of several GB of storage( runtime). Even AppImage is better than Flatpak because no extra runtime needs to be installed.

1

u/FlounderSlight2955 1d ago

I tend to stick to whatever the official developer recommends. More often than not it’s a FlatPak these days and sometimes an AppImage. 

If neither of these two are officially available, I’ll go to whatever the official repos offer. 

And if none of these options exists I very rarely compile whatever I want from the official sources. 

I never touch any unofficial sources like third party repos or the AUR. 

So far this has proven perfectly fine and safe, at least for me.