[derefr]

> devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro

I mean, no, those aren't the only two solutions. As with accessibility requirements for public-access shops, "we the users" could mandate (either through legislation, or more interestingly, through some kind of medical/legal-like software-engineering bar association) that devs either properly package their apps, or don't release them at all.

I'm not saying it's a good idea; just saying that it's probably the solution brewing in the back of the minds of people who write things like this.

[kybernetikos]

> devs either properly package their apps, or don't release them at all.

There's still no widely accepted answer for what 'properly package their apps' looks like. You could want snaps or appimages or a flatpak, or rpms or debs or docker containers or nix flakes or cargo crates or python virtual environments or jars or javawebstarts or portable windows executables or windows msis or webasm packages or web pages ... there's an impossible profusion that it's currently unreasonable to expect devs (many of whom are working for free) to support more than a couple of.

If there were a single solution that worked in almost all cases and platforms, didn't put unreasonable constraints on packagers and was widely adopted, then it might be somewhat reasonable to expect devs to support it, but that's far from the world we live in. The closest to that (despite its real problems) is probably piping a curl to a bash script...

[ilyt]

>There's still no widely accepted answer for what 'properly package their apps' looks like. You could want snaps or appimages or a flatpak, or rpms or debs or docker containers or nix flakes or cargo crates or python virtual environments or jars or javawebstarts or portable windows executables or windows msis or webasm packages or web pages ...

Any single one of them is better than curl|sh. Just pick one. Even shipping raw runnable binary blob is preferred.

But to classify, as long as it is a unit managed by a system that can be wholly removed (sans data/configs, as you might want to keep those), it works well enough as "package">

> there's an impossible profusion that it's currently unreasonable to expect devs (many of whom are working for free) to support more than a couple of.

...I don't think I ever saw anyone asking to support more than one for a platform. Obviously users on MacOS (assuming app even releases there) will complain if you only have .deb packages but you won't get many "oh, only .deb ? I wanted a flatpack!"

[kybernetikos]

> I don't think I ever saw anyone asking to support more than one for a platform

What do you mean by platform? If you only ship a .deb, there are going to be a lot of linux and unix users who simply can't use your stuff.

I've seen quite a few tools use curl to bash to work in macOS, windows and multiple flavours of unix. There aren't a huge number of other approaches that can allow that.

[mynameisvlad]

I mean, that will just result in no software ever getting made outside of big companies who can afford entire departments of people specializing in packaging.

If someone were to impose restrictions to the hobby things I do, then those hobby things will just become private repositories that will never see the light of day, and I'm sure that rings true for most people.

[mustache_kimono]

> "we the users" could mandate

Yuck. As I said:

> Instead, it is always someone else's problem.

"I am the customer mentality" has been with FOSS and Linux for awhile, but one wishes people might shake themselves out of their stupor for 2 seconds to realize: "You're getting all this stuff for free." Instead, every user wants to man the battlements on Reddit and tell devs how to do the thing.

Re: the parent, she/he shouldn't be downvoted for making an unpopular yet interesting point.

[denton-scratch]

> "You're getting all this stuff for free."

Of course.

Part of packaging something, and then releasing it through a distro's package manager, is that it goes through the distro's release process; someone reviews it. It becomes part of the distro. In particular, if it goes into something like Debian's "main" repository, I'm inclined to trust it almost as much as I trust the core OS release.

I'm not going to man battlements anywhere over this kind of thing; but I'm not going to execute arbitrary shell scripts downloaded from the internet without reviewing them; and 600 lines of shell-script is more than I want to review, unless I'm super-motivated. If the only way of installing a package is Docker (which I don't care for) or wildcat script, and that package has no maintainer for my chosen distro; that's fine, and I'm not going to beat up the developer. It's not his fault, nor his responsibility.

So instead I generally look for an alternative package that's shipped by my distro. I don't keep a record of all the wildcat software installed on my systems, because there usually isn't any, and my package manager knows exactly what's installed.

[mustache_kimono]

> I'm not going to man battlements anywhere over this kind of thing

Totally agree. A preference is fine. A demand that devs do something different with their limited time and resources is nonsense. Making the choice not to package and distribute is fine. Then -- it just becomes someone else's problem. You hate omz's update method? Then be prepared to package it yourself. That's all I'm saying.

[Brian_K_White]

Yet somehow as a developer I have no problem at all realising that it is user-hostile to take liberties with their system.

It's violating trust and I have no need to do it in order to provide, even to install, a piece of software.

[mustache_kimono]

> It's violating trust

`curl | bash` is pretty upfront about what it is. It would seem the user is the one taking liberties, but perhaps I'm missing your point?