[mustache_kimono]

> If my package manager had an Oh My Zsh package

This is the author missing the point. The reason `curl | bash` is common is because 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. Instead, it is always someone else's problem.

Package managers are great... for the user. For everyone else, a polyglot system, with arcane technical policies, and even more arcane human policies is... not ideal.

[ilyt]

The effort to package is precisely what the complaint is about; you have to tell (in package manifest) where your files land and which are app files (to be removed freely) and which are config (user might want to leave it, won't be automatically overwritten on update)

> devs don't like packaging for every distro under the sun

source .deb will generally works fine under Ubuntu, Debian and most flavours just fine unless you have some funky dependencies (and if you do, installer will also be complex)

RHEL/Centos RPM will cover near-whole rest of the market.

MacOS/FreeBSD will be different enough anyway that you will need to write a bunch more in install script

Building simple package that just delivers binary is not even that complicated. Getting them to pass distro muster is often harder but you don't need to do that.

> Package managers are great... for the user. For everyone else, a polyglot system, with arcane technical policies, and even more arcane human policies is... not ideal.

Most of those "arcane" policies are there so random incompetent dev won't fuck up other stuff in the system. Which is also why users want packages in the first place.

And you don't need to abide to any policy to make simple package that just puts your files on the system. Building dumb debian package is just few metadata files (post/preinst scripts + a file describing your package) in a directory and a single command.

You only need to worry about policies if you want to submit package to distro, and there are in place for a reason.

No shit they are better for users, that's their entire fucking point!

[mustache_kimono]

> No shit they are better for users, that's their entire fucking point!

I'm not even sure we disagree about anything, and you're yelling? FWIW I package and distribute my software but for a long time I didn't.

My position is very simple -- it's always easier if someone else does the work for you. If someone chooses not to distribute with a package, that's fine. If it bothers you, the choice is to build a package spec and pipeline for that project, not to moan about it. But packages are not an entitlement of a non-paying user. That user is perfectly entitled not to use your software, because complaining about the packages you may or may not have available is stupid, and not the devs problem.

[bravetraveler]

With things like the OpenSUSE build system... I see this more as a one time cost

You write the spec files for the managers of choice; DEB, RPM, PKGBUILD, whatever

With that you parameterize the inputs. The version to build, where to get the sources, etc.

Maintaining these is... note your build/runtime requirements the same way you do while developing.

Once the specs are written the laborious work is finished. There are countless tools to make this less effort, eg: pyp2rpm and alien

I maintain packages through Fedora COPR, a similar system. These tools are my first pass at writing the spec for things I don't even own.

I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it.

This is a critical first step to being bundled in the distribution itself. You won't get maintainers if there's nothing to maintain.

[ilyt]

Pretty much. I've built a few for the internal stuff and it is essentially one time effort for DEB based platform.

Clowns at Red Hat do like to break manifest compatibility in the worst way tho, think "a macro with same name in new version now does something else". The idea of .spec file being whole manifest is... nice in theory, not in Red Hat execution. But then last time I did any for RHEL was at RH6/7 time, maybe it's better now...

But even in that case that's fixing few minor things every 3-5 years at worst. There is no excuse to not make your packages if you're actual serious developer, not some random hobbyist.

I do give a pass for apps that run as single binary as that while suboptimal is at least easy to work around.

[bravetraveler]

Oh you're right, that surprise macro dance is an absolute pain.

Being on Fedora I run into this a little more regularly than you would on proper RH these days, it's like the prerelease playground.

If you (or anyone) had things building fine for Fedora 36, they may not on 37. I forget which but one of the macros I repeat moved packages

One of these likely translates to a future Red Hat release

[mustache_kimono]

> I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it.

I've heard a lot about these systems, and, if they do what they promise, I think this is great. Exactly what is needed. I already do package and distribute my software. My comments are mostly directed at those who have a problem with those who don't, because that's a fine choice too. It can also be a fine choice for awhile. The problem is mostly one of attitude, we need less user entitlement re: packages. Packages are something I will get to if I want to, when I have the time, and if it interests me.

I would note there are other problems with the package manager ecosystem which make it ill-suited to packaging Rust apps, for instance. I am not an Arch user, but Arch really is leading the way here: https://wiki.archlinux.org/title/Rust_package_guidelines

[bravetraveler]

Thank you for the packages you do maintain!

I don't want to seem unappreciative for the work developers like yourself and others do; packages or not.

I'm not a developer, but a Linux/systems person who happened to learn packaging. Mostly because I got tired of building from source, and figured others were too.

As a maintainer it is easy for me (and others) to trivialize this, as compared to actually writing the much more complicated software. It's not right, and I think we could all use more understanding.

I see a meme that 'packaging is hard', and while very rigid/plain, it's not actually that tough.

Priority is another matter, I just don't want this notion of difficulty to unfairly sway that priority. Many of the concepts reapply, like languages. The tooling/services have improved a lot

I'm not too familiar with Rust, unfortunately. What would you say makes Arch stand out in particular?

How do you feel about Fedora? https://docs.fedoraproject.org/en-US/packaging-guidelines/Ru...

[simiones]

It's even worse than that. The way common distros work is not "devs package software", it's "devs convince distro to pick up the package and maintain a fork".

Of course, you can run your own APT or RPM repo, but that actually asks your users for even more control of their systems (since you now have a way to get any new version more or less automatically installed on their system in perpetuity), and it makes it even harder for them to install your software.

You can also bundle your software as a .deb + .rpm + .[...] file instead of a .sh file, but there is really not that much difference.

[ilyt]

> It's even worse than that. The way common distros work is not "devs package software", it's "devs convince distro to pick up the package and maintain a fork".

> Of course, you can run your own APT or RPM repo, but that actually asks your users for even more control of their systems (since you now have a way to get any new version more or less automatically installed on their system in perpetuity), and it makes it even harder for them to install your software.

Technically incorrect as you can put (at least in apt) filters on what's allowed from the repo

Also, you want to have your cake and eat it too.

Either there is some 3rd party to look at package quality (even if "quality" in this case is "does not fuck up other stuff" and "uninstalls properly"),

or you trust developer to not fuck you over when they update the package

or you don't and only install raw .deb file.

> You can also bundle your software as a .deb + .rpm + .[...] file instead of a .sh file, but there is really not that much difference.

Main difference is that package can require system deps (so you will be sure that they are not removed on accident) and you don't need to write uninstaller for it.

[derefr]

> but that actually asks your users for even more control of their systems

Or you can support one of the limited-capability package ecosystems, like Flatpak or Snap or AppImage. Then it's sort of like installing an app on your Android phone: the installed app (and its updates) only get to interact with the system through a customized sandbox that must first be described to, and accepted by, the user.

[simiones]

Sure, but there is plenty of software for which that doesn't make any sense, since the whole point is to interact with your system. ohmyzsh is a good example, as are most SDKs, as is plenty of specialty software.

[derefr]

SDKs are an interesting case — it wouldn't work to package them into a sandbox by default, but do look at how macOS treats XCode for an example of how something can be "sandboxed" but still reach out into the system by the system instead actually reaching into it. A thin layer of non-sandboxed system components on macOS "expect" XCode, and so work with it if it's available, to extract specific sandboxed data from the XCode sandbox and so "publish" it into being standalone software (rather than software that ends up also running inside the XCode sandbox.)

Essentially, an SDK in this sense would be a sandboxed plugin for a non-sandboxed system-level meta-SDK manager, that knows how to use these SDKs (in their sandboxes!) to compile and/or test-run things; where a test-run gets granted capabilities that the SDK-as-compiler does not itself possess, per a capabilities manifest fed in with the meta-SDK development project.

[AnIdiotOnTheNet]

AppImage is not "limited-capability" and has no sandbox mechanism at all without additional tools. An AppImage is the rough equivalent of a statically compiled binary.

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

[bombcar]

Even if omz had a package-managed package, it would do the basic curl|bash itself the moment it was installed, to update itself. Technically it's git and things, but that's all the curl|bash does anyway.