Appimages, snaps and flatpaks, which one do you prefer and why?

  • ELI70
    link
    fedilink
    arrow-up
    2
    arrow-down
    3
    ·
    1 year ago

    tbh never looked into snaps flatbacks or appimages. However my instinct as a staunch linux is that anything besides apt-get or apt or aptitude is utter trash. we already have apt, why do people feel the need to divert energies to these unneccessary packagemanagement-fads?

    • KrispeeIguana@lemmy.ml
      link
      fedilink
      arrow-up
      6
      ·
      1 year ago

      The problem here is that there are so many linux distros that are trying to do their own thing. Sure, a Debian-based distro would use apt, but a lot of the other distros like Void and Fedora use different package managers to suit their needs. I personally use Arch Linux, and that uses pacman which is my manager of preference. There are packages that I cannot find and/or install via pacman and the AUR due to them either not being built as an Arch binary, or being left abandoned by the developer who couldn’t bother supporting multiple distros and their package managers, or not having a compatible dependency built for my system.

      Flatpaks and AppImages allow for a developer to place an application and all its dependencies in a neatly packaged group. This allows developers to only need to create one package that works on many distros and won’t be affected by dependency changes. I use a Flatpak package for Steam because, due to the rolling-release-nature of my distro, sometimes the native install breaks and/or doesn’t open properly.

      In theory, Snap works in a similar way as the other two, but that is a proprietary package manager that doesn’t work on my distro without far much more effort than needed for any proprietary software should ever need to get working ever.

      The only real downside to these package managers that I’ve seen is that the package size is larger than any native install. I am personally fine with this tradeoff however, as I have gotten quite used to building Python container environments recently.