[Sakos]

> I would have just expected it to install it in the proper location (hopefully not in my home directory) and leave the rest of the configuration to me

While I don't advocate for piping curl to bash, this is exactly what I expect an installer to do. It should provide sane defaults that don't require me to fiddle around with manpages or other documentation and config files before I can even use the thing. I'd say that's even the standard for most software. Now, I might compromise on the installer telling me what command I need to enter to get a default configuration/setup integrated instead of doing it automatically, but I have too much shit to do to waste it on configuring the nth thing I've installed this week.

I think what's missing is some standardization around what an installer is allowed to do and flags to tell it when to make certain changes as well as explicit logging for what exactly was changed or added where, but that's not going to be solved if everybody has their own bespoke bash script for installation.

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

[ilyt]

>I think what's missing is some standardization around what an installer is allowed to do and flags to tell it when to make certain changes as well as explicit logging for what exactly was changed or added where, but that's not going to be solved if everybody has their own bespoke bash script for installation.

YOU ARE RIGHT!

What's more, we can make common installer code so everyone could just use same rules and documentation to customize it to their liking.

And once we have many apps using it might even be integrated into system so you don't have to download as much, and all the bugfixes are in one place so we don't have thousand different install scripts

Once we have that we can just make a very simple data file format, say just a data.tar.gz for data and control.tar.gz for telling installer what to do. As for metadata, just write simple file, say

    Package: my-tools
    Version: 0.0.1
    Section: base
    Priority: optional
    Architecture: all
    Maintainer: Someuser <some@email>

If you need to run something after installer just put it in control.tar.gz as postinst script and it will do that

And if that's one format, we can it manage uninstalls too! Just put a simple text database of those files.

OH WAIT THAT'S A FUCKING DEBIAN PACKAGE MANAGER

[Sakos]

You could've at least looked at the replies to my comment before ranting pointlessly.