[spsesk117]

> I think what's missing is some standardization around what an installer is allowed to do

I don't mean to be facetious, genuinely curios, but to the authors point, isn't that the point of the package management system? It's a standardized and encapsulated way to provide software, with sane defaults, in an auditable way, that respects the users system.

I tend to agree with the author here, but I'm sympathetic to the maintainer: packaging for rpm/deb (in my experience) can sometimes be an enormous pain with many hoops to jump through, _especially_ if you're trying to get your package accepted upstream. With that said, it is a mature, standardized process, and is fairly painless in the self-hosted/non-upstreamed case.

[Sakos]

> packaging for rpm/deb (in my experience) can sometimes be an enormous pain with many hoops to jump through, _especially_ if you're trying to get your package accepted upstream

I would say this is the primary pain point for maintainers, which is why we're suddenly seeing bash scripts instead. The technical complexity and the process of upstreaming and then doing this for a bunch of different distros. If they're already rejecting package management systems because of their current state, the solution isn't "well, why don't they just use existing package management systems".

[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.

[ilyt]

The person you cited is either lying by omission or don't have a clue.

Getting package up to distro standard and have it included in distro can be complex

Making a package ? Nope. Make a dir tree

    ./DEBIAN/control
    ./usr/bin/yourapp

make a control file

    Package: my-tools
    Version: 0.0.1
    Section: base
    Priority: optional
    Architecture: all
    Maintainer: Someone <some@email>
    Depends: etckeeper (>= 0.40), git-core, iotop, iftop, links, mc, multitail, mtr-tiny, nmap, psmisc, screen, tcpdump, curl, socat
    Recommends: swaks, atop, ntpdate
    Suggests: hping3
    Conflicts: vim
    Description: Some random tools
     tools i use for everyday work

run one command

    fakeroot dpkg-deb -b my-tools

and you sir are fucking DONE.

want postinst script ? shove it in ./DEBIAN/postinst

want to tell package manager "those are configs, don't replace them on upgrade" ? Put a list of them in ./DEBIAN/conffiles

in case of RPM all of that info is even in single file (altho bit more fuckery IIRC) but if you are lazy you can just make deb package and convert it to RPM

Making simple package is EXTREMELY simple. Checks ran by distro are not but they need to make sure your package doesn't leave crap or break anything else so IMO that's understandable, you can just host somewhere else if you don't agree with distro policies.

[spsesk117]

I don't think I implied making a package wasn't simple...from my comment:

> With that said, it is a mature, standardized process, and is fairly painless in the self-hosted/non-upstreamed case

[prmoustache]

There is no way a monolithic bash script full of if statements and list of dependencies for every single possible linux or bsd distribution is more maintainable than having a clean set of RPM spec, APT control, AUR PKGBUILD and BSD packages makefiles.

Devs who use curl | bash do that because they are control freaks and want and love to make mess in user's homedirs, that is all. This is a an ego issue, not a technical one.