I love how he literally packages for any system EXCEPT snap
That would make it worse. Then it would only be usable on systems based off of canonical. Not even debian. Snap does have a few small technical benefits over something like flat pack currently. But if you want to just package it and run it anywhere. Flat pack is the go-to
I think you can install snaps on Debian
They already support many repos. Adding Snap does not make it worse for the others.
Do nix and then use nix2appimage, or nix bundle to package the app compressed as an arx archive without the startup times they complain about.
You can also use https://github.com/DavHau/nix-portable to bundle it a bit better, without needing nix on the host.
And then, based off a quick search:
https://github.com/neobrain/nix2flatpak
https://github.com/barstoolbluz/nix2deb
I couldn’t find nix2rpm or nix2pacman, but there exist tools to convert between formats (alien, debtap, rpmtap, and one more who’s name I can’t remember but I remeber as being the most versatile).
What I’m trying to say, is that when people said “just use nix”, they probably really mean to use nix as a platform to build other packages withouth doing extra work.
On the other hand,
You can also use one of the newfangled appimage like formats: https://docs.pkgforge.dev/formats/packages
This one is linked in there and creates a static executable from any binary: https://github.com/VHSgunzo/sharun
Now they would still have to build for macos and windows, but they are already doing that anyways.
As a sidenote, there is also this: https://github.com/pacur/pacur , which is an aur like repo that buids debs, rpm’s, and pacman packages. So there’s semi-automatic updates, via a publuc repo you can out stuff on.
The real elite solution, imo, is to host forgejo, or use codeberg, which insanely has a package registry for every possible format of packages. So you can directly just push there, after building however you want.
But if developer’s were good at packaging, I wouldn’t be so mad when they try to do it.
Because this:
The next version will include a new built-in self-updating mechanism
Downloading unsigned, unverified binaries directly from the latest versioned github release?
Makes it so that all that’s needed for getting malware on the system is pwning the developers account via some supply chain malware, that hooks into there browser and pushes a release.
And every additional developer who can release, or every github actions that is potentially vulnerable but can be made to release, or claude (since the author is letting it commit, which requires it to run without sandboxing afaik) becomes more attack surface.
There are ways to fix this. Conventional distros use multi party signing of commits and releases, where developers continously verify eachother and look over changes.
More newfangled flows involve using github actions to build immutable releases, directly from tagged versions of the code.
But random developer #3989 isn’t doing this. They are distributing their software in a way that malware distributors will be ery happy to see after pwning their account.
I want devs to use nix, because then I can build or run their program directly from the source code. It sidesteps so many issues with visibility of the supply chain, or being unable to inspect what I am running.
I like nix becuase I can make developers like the above satisfied by giving them a way to easily build static binaries, or other formats.
Yeah. Honestly it might be a good idea to start a community project that’s a “nix2everyDistro”, and then go around and open PRs on FOSS projects to wire their project up to build in nix + output “every distro”
What I’m trying to say, is that when people said “just use nix”, they probably really mean to use nix as a platform to build other packages withouth doing extra work.
What you should be saying is something that recognizes that not all systems adhere to FHS. It needs to account for the non-compliant ones, and that includes Lennart’s delightful deviations when he obviously just knew better than the Industry.
So what’s wrong with just releasing a monolithic static binary for each architecture you want to run it on?
I read the post, and it sounds like what the author did in the end. I just don’t get why it was the last thing he tried. I don’t get why Linux software packaging has to be so complex.
So what’s wrong with just releasing a monolithic static binary for each architecture you want to run it on?
Release engineering works on something that has only recently been codified into a SLSA scale. At the top end is nixos and their very firm validation of code all the way along the supply chain.
At the bottom of the scale, a SLSA score of 0, is “here’s a monolithic binary I found on the website of someone on the interwebs. Even though we don’t know how it was built, nor can we reproduce it or confirm it’s what he built or look at any of the parts to see whether the statically-linked libraries are now at-risk, let’s just run that.”
You … do see how irresponsible that is on every level, right?
Like, 20 years ago I dropped a patch in for Apache, and these days I manage reams of machines using apache, sendmain, winbind, nginx, postfix, etc; to manage those without a proper infrastructure is absolute madness.
I seem to recall many years ago having to build some rpm packages. It was really not that difficult iirc. Cant imagine .deb or whatever is all that much harder.
deleted by creator
When I packaged software, I did RPM for Fedora and openSUSE (because that’s what I used at that time) but out of curiosity I looked at .deb as well and boy are there weird things there.
There are many similarities between RPM and pkgbuild for Arch, so I could easily copy almost entire pkgbuilds from AUR and merely adapt a few variables but whatever the inventors of .deb concocted is crazy. Archives within archives and other stuff I actively repressed memories of.
I looked at .deb as well and boy are there weird things there.
There are many similarities between RPM and pkgbuild for Arch, so I could easily copy almost entire pkgbuilds from AUR and merely adapt a few variables but whatever the inventors of .deb concocted is crazy.
That build method dates back super-far, and probably mirrors unix packaging of the day. This is not a good thing, in that it did miss out on some validation features that RPM and NIX have, and that’s a problem that hasn’t been fixed (in unix or debian) even now (25+ years after we noticed it in the enterprise OS company I worked at, and which invalidated debian even then as a product we wanted to support alongside unix).
I do release a Flatpak but I’m actually working against it. It’s designed for self-contained sandboxed desktop GUI applications and I’m releasing a terminal-based TUI that allows you to rampage around your machine and network. I’m passing some horrible “bad practice” flags to get it to work. Flatpak sandboxing is not a good fit.
Okay sure but is this really such an issue? Installing the app normally is equivalent to passing those flags anyway right?
It is equivalent until Flatpak adds a new (probably completely justified) limitation to its sandbox that breaks your (needs unrestricted system-wide permissions) application, sure. Nevermind if you decide to add more features that go beyond what the sandbox allows, and then you need to figure out why they’re broken in your flatpak and what new flags you need to unbreak them. The problem is you’re constantly swimming upstream against a very strong current. It’s not a very sustainable mode of development. Like OP said, flatpak is designed for sandboxed desktop GUIs. It may be convenient at first to shoehorn your TUI application into it, but you’re working against its design and intent, and that is a genuine problem, for many reasons.
npm -gis another TUI install method I loathe. pipx/uv shares most of the same issues. Like the author, I’ve gone through almost all of the same options they have, and come to basically the same conclusions. There really is no good option for packaging and managing userspace TUI utilities. And it’s brutal. I hate that so many terminal utilities have standardized to use completely unrestricted, opaque and dangerous curl/sh copy-pastes, leaving anyone who’s not both fluent in shell script and willing to invest the time to inspect what the scripts are doing out in the cold, bravely running commands that are potentially malicious with no safety net. I understand it, it’s viable, it works, I do it myself for my own projects, but we have to acknowledge that it’s a symptom of the lack of any better solution for TUI packaging, and it’s okay to admit that it sucks, and we could do something so much better.I’ve installed one TUI app through brew (spicetify) and it seemed perfectly cromulent.
