One of the strongest points of Linux is the package management. In 2025, the world of Linux package management is very varied, with several options available, each with their advantages and trade-offs over the others.

  • kixik@lemmy.ml
    link
    fedilink
    arrow-up
    11
    arrow-down
    15
    ·
    1 day ago

    I’ve tried in the past flatpak packages, they are terrible in many senses the proponent (vast majority AFAIK) don’t say, among them:

    • They create huge static binaries
    • One gets many libraries embedded in the static libraries or local static libs to the package which are often repeated among many static binaries, even the same version of them. This is totally avoided when building against dynamic native libraries.
    • When installing a pletora of static dependencies for a package, lets say liri, a bunch of the stuff it requires might already bi installed natively in your system, but they need the static deps locally part of the package.
    • Care must be applied, there are statistics available about abuse on vulnerabilities infection on pypi, npm and so on, this no different on these packagers repos/hubs.

    Good that they provide an alternative way to install packages not available in your distro repos, but for that user repositories building against native libraries are a much better option, like AUR in the case of Arch, and even their binary packages coming from other distros or from upstream might be even better than those universal static binaries providers.

    There are political aspects involved in the past claim from the proponents, and it’s that in their view gnu+linux echo-system should become like the windows one, where everyone company or org (to them doesn’t matter) should be able to provide their binary packages, and then there’s no reason to think of anyone being able to build their staff.

    There’s a tendency actually on providers on those hubs, to ignore problems on people who tries to build their stuff on their own, claiming they only support those universal packages. Which to me it’s dangerous, since it goes in detriment to the ability to build and distribute the software, which might not be due to licenses, but rather practical reasons. This might actually be against the licenses they use, but now a day who cares, right, it’s available on that packager repo…

    Lastly one argument provided in favor of the apps coming from those universal packages is sandboxing. But there’s firejail which can be install on most gnu+linux distributions, and comes with profiles for a pletora of apps, and if sandboxing is not enough, it can easily be combined with apparmor, or if you prefer selinux might be used… No need for those universal packages to have a sandboxed experience.

    One final note, so far gnu+linux has been characterized by having a diversity, which is good, that diversity offers people options to choose from, and a lot of different solutions for different purposes. Not so long ago the claim was that it was not good, that meant fragmentation, and fragmentation is bad for adoption and maintenance. I see it the other way around, this diversity allows for choosing for what aligns better with the user intends, like easy to use, or rolling release, or as vanila as possible, or as up to date as possible, or as hardened as possible, etc, etc. Systemd is another example of this universalization intended. Perhaps some distros prefer to be a shell for systemd and get packages just from universal packages, that’s bad news to me.

    Of course having universal packagers present an oportunity for corps and orgs to also provide stuff on the gnu+linux platform, but in my mind the best would be for them to offer free/libre and open source software, that would build on any system and be provided by any packager that wants to offer it. Though I believe that to be too idealistic perhaps. Jeje.

    • LeFantome@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      11 hours ago

      To understand how to interpret these complaints, we need to understand that Flatpak works by essentially installing a second set of libraries for your apps to run on. The apps run in a container (much like Docker) on top of these libraries. Flatpak uses the kernel and display server from your main distro but otherwise Flatpak is like a second distro unto itself.

      So, if you only install a Flatpak app or two, it is very true that they will require quite a large number of support libraries to run (just like running one app on your distro is more distro than app space wise). However, as you add more apps, they they resuse the libraries that the first apps installed.

      Because Flatpak installs all its own support libraries, the apps run the same on all distros (which is the point).

      So, Flatapak does duplicate the libraries on your system out of necessity. Because your Flatpak apps does not use any of the libraries from your host system. However, they are only installed once inside the Flatpak environment.

      The comments about vulnerabilities are neither here nor there. You have to trust your distro. You have to trust Flatpak (as a second distro). Both are subject to vulnerabilities and supply chain attacks but neither more than the other. Flatpaks are technically after as the container environment they run in “sandboxes” your Flatpak apps. In practice though, they require enough permissions that the sandbox is trivial to escape. So not much difference.

    • chunkystyles@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      7
      ·
      17 hours ago

      There’s a good deal of misinformation here. The main part being disk space. While it is true that flatpak apps will take up more space, it’s not nearly as bad as you think it is. There is a lot of really good optimization going on under the hood that you don’t see. Dependencies are de duplicated. I’m no expert on it, but I believe that dependencies also have delta changes from one version to the next.

      Regarding apps not supporting building of the source, you should get over that or do the work of supporting it yourself. Open source is a hard, usually thankless job.

      • kixik@lemmy.ml
        link
        fedilink
        arrow-up
        1
        arrow-down
        1
        ·
        5 hours ago

        I installed liri-shell, and some other apps some time back, and totally disliked the experience. Too many duplicated stuff, which was totally unnecessary. While I can, I void universal packagers.

        I’m not complaining about open source, I’ve been using FLOSS for so many years now. The thing with developers only supporting universal packages distributed binaries is that the build recipes might be too tight to them, or not explicitly exposing all dependencies, and several other things. I have no issues building and installing software. So that’s not it. All I said was that to me closing bugs because not using the universal package supported is sort of crazy, being open source and supposedly being able to build and distribute. I didn’t say I couldn’t support myself.

    • Ashley@lemmy.ca
      link
      fedilink
      English
      arrow-up
      9
      arrow-down
      1
      ·
      23 hours ago

      cons:

      • dependencies

      we get it and don’t care. they’re convenient and work well.

      • kixik@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        4 hours ago

        I know most don’t care. I initially stated most people don’t agree with me. This is just my take on universal packages in general. I really like and appreciate the typical shared libraries native to most distros. It’s OK we disagree, I only hope we don’t end up with empty shells with systemd and everything else on app stores…