[spsesk117]

> the solution isn't "well, why don't they just use existing package management systems"

Fair enough, I think I was more trying to unwrap the idea of "shell script standardization", which to me feels like a package management system.

To your point about the challenges of packaging for multiple distros, there are force multiplying tools I've used in the past that make this easier, but in my experience it is always a big challenge.

My hope is that things like Nix or even something like brew can help to further consolidate the installation process for software going forward, so that everyone can have the best of all worlds :D

[Sakos]

> Fair enough, I think I was more trying to unwrap the idea of "shell script standardization", which to me feels like a package management system.

And you're right, of course. I just think it's important to recognize what is being compensated for when existing solutions are rejected. We have a habit of saying "they shouldn't be doing that, we have this already" instead of "this is a signal that something in the environment is making what they're doing a viable alternative, how can we improve things?"

I don't think it's an accident that we're seeing the rise of Snap and flatpak or even Nix at the same time.

[ilyt]

> I don't think it's an accident that we're seeing the rise of Snap and flatpak or even Nix at the same time.

It's not because making packages is hard, it's because making sure you bring your app dependencies with you is.

It is generally a problem for languages that are not self contained (like Go, Java) but need a bunch of .so libs to run.

Distro's attitude is pretty much "we want X version of lib, we will support that version and focus all patches on this version for this release". It works, it keeps things stable (you know exactly what you need to target with your app), security update of a library hits every app using that library but it is PITA if

* your app needs something newer for features

* lib your app uses is not in distro already, then you need to either embed it with main package or package that too.

* your developers can't even figure out which version is enough so they just pull whatever is on their desktop as "production" dependency".

All the effort there is in making sure devs that can't figure that out at least use same base (docker's FROM being one example) and that they don't have to package all the other stuff that app needs in separate packages (docker/flatpack/appimage),

"Fat" packages like that obviously have some benefits, but, well, in distro I can upgrade OpenSSL and now every app is safe, in flatpack/appimage/docker-ridden environment every single of fat packages need their maintainer to care enough to upgrade so generally while easier on dev effort they are security disaster waiting to happen.