My main complaint about solutions, like Flatpak or Snap, is that they add another package manager. Now I have to manage two sets of packages.
The baseline tools, like all the GNU standard Unix tools, and other command line tools are still managed by DNF, APT, whatever, and then another set of apps are managed by Snap. It's pretty confusing, especially if you never use the "app stores" otherwise. You quickly end up with: apt install <some command line tool> and apt install gimp, but now that's a different Gimp than the one in App Store. You also can't really remove Gimp from apt, because it's weird that apt can't install everything.
I haven't really used Flatpaks, but Snaps is confusing (to me at least), because it's doesn't actually replace APT and pollute the output of "df" and "mount".
I'm also concerned that some packages will never be updated, or stuck on a library with security issues. Perhaps that me, but I'd rather that that one application breaks.
You should point the finger at package managers. They never really addressed needs outside of system administration (to be fair, that's the problem they were trying to solve). Scripting languages came up with their own package system because package managers didn't fit their needs, I often found myself building from source and installing into my homedir because package managers wouldn't accommodate, industries (like the one I work in) came up with their own package management outside of the OS.
Nix/Guix seems like the only one that's trying something different enough to address some of those other use-cases, but the cat's out of the bag for most people.
>You should point the finger at package managers. They never really addressed needs outside of system administration (to be fair, that's the problem they were trying to solve). Scripting languages came up with their own package system because package managers didn't fit their needs
I argue that's simply not true. Scripting languages came up with package managers because the largest platform (Windows) does not have a package manager. Actually that scripting languages implement package managers is a very good argument that their functionality is desired. As a side note, every language package manager is much worse in my experience than all of the system package managers I ever used.
Right. Windows support is a feature outside of the scope of Linux package managers. If they weren't tethered to specific distros I don't see why one couldn't support multiple platforms. It hasn't historically, but Windows has a bunch of package managers, even one supported by Microsoft.
I think "largest" is quite an exaggeration since historically scripting languages packaging has been rather terrible on Windows. While Windows was a consideration for languages like Python (I've read they avoided Make because of Windows), for me cygwin always coming up along with it until recently.
> Nix/Guix seems like the only one that's trying something different enough to address some of those other use-cases, but the cat's out of the bag for most people.
Maybe that's because nix and guix don't interop despite having rather similar principles, and because we mostly don't have GUI for it (like GNOME Software has integration for flatpak) nor desktop integration (like AppImageLauncher). Are you aware of work being done in this space?
I wasn't trying to undermine their hard work! I think both have a chance of being successful in their own domains. I only meant to call them out as exceptions.
All I was saying is that if a new package manager addresses all of the issues scripting languages had, scripting languages would still use their own package managers. Because the culture is now set, even new scripting languages would write their own package managers.
Package managers that integrate apt, flatpak, and (potentially) snap are a nice solution. Unfortunately, the one that happens to be on my system (Pop!_Shop) is awful.
Could you maybe elaborate, or link to more detailed criticism of Pop! Shop? I've also found that GNOME Software did a rather poor (though not that bad) job of exposing the multiple sources for a given package, but i believe this can be fixed with better UX (though i'm unaware of work being done in this space).
Pop!_Shop's UI frequently freezes when installing, searching, or even just opening an app's store page from the Gnome app menu. It also has some UI bugs, like the search bar being visible but un-interactable when on an app's page. It's definitely something that can be fixed with better UX. The actual selecting whether I want the apt version or flatpak version of a package works fine.
The baseline tools, like all the GNU standard Unix tools, and other command line tools are still managed by DNF, APT, whatever, and then another set of apps are managed by Snap. It's pretty confusing, especially if you never use the "app stores" otherwise. You quickly end up with: apt install <some command line tool> and apt install gimp, but now that's a different Gimp than the one in App Store. You also can't really remove Gimp from apt, because it's weird that apt can't install everything.
I haven't really used Flatpaks, but Snaps is confusing (to me at least), because it's doesn't actually replace APT and pollute the output of "df" and "mount".
I'm also concerned that some packages will never be updated, or stuck on a library with security issues. Perhaps that me, but I'd rather that that one application breaks.