this post was submitted on 30 Aug 2026
56 points (91.2% liked)

Technology

87649 readers
2831 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 3 years ago
MODERATORS
top 27 comments
sorted by: hot top controversial new old
[–] nyan@lemmy.cafe 33 points 7 hours ago (1 children)

Just give the source away. Don't package it at all (or at most, do so for your own distro). If your software is good enough, others will do the packaging for you. You'll have to field a few inquiries, maybe, until someone steps up, but if you've got a canned response already written those don't take long to handle.

This dev's problems are twofold: first, he's in too much of a hurry to get this thing out everywhere, instead of waiting for others to take the burden off him. Second, he wrote his code in Rust, which is difficult to package correctly in a self-contained manner because it tries to force you into using its own language-specific dependency system. He picked up a footgun and shot himself with it, in other words, and is now hopping around cursing.

[–] Skullgrid@lemmy.world -2 points 7 hours ago (1 children)

He picked up a footgun and shot himself with it,

But I thought rust was 100% safe and the best? /s

[–] nyan@lemmy.cafe 8 points 6 hours ago (1 children)

There's nothing wrong with the language that I'm aware of, but some aspects of the ecosystem seem to have not been thought out with Linux packaging in mind, let's say.

[–] Skullgrid@lemmy.world 0 points 5 hours ago (1 children)

I'm just making fun of the people who treat rust like the next best thing after sliced bread and pretend it will make it so you have 0 bugs.

[–] ripcord@lemmy.world 3 points 3 hours ago (1 children)

Well, that sounds really immature.

[–] Skullgrid@lemmy.world 0 points 2 hours ago (1 children)

Their behaviour or me making fun of them?

[–] PotatoesFall@discuss.tchncs.de 2 points 4 hours ago (1 children)

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?

[–] cecilkorik@lemmy.ca 3 points 3 hours ago

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 -g is 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.

[–] notabot@piefed.social 42 points 9 hours ago (4 children)

No automatic updates for .deb / .rpm

The author seems to have completely missed the point that they can just publish their own repositories to allow users on both of these platforms to update. It would also mean they could avoid the problems they're having building source packages.

Their complaints about supporting instalations with older libc versions are also addressable by just building against the oldest libc they wish to support.

[–] liinux@pawb.social 1 points 3 hours ago (1 children)

Can't you just put all your packages in the same repository but different directories? Example: debian/.deb, fedora/.rpm, appimage/appimage...

[–] notabot@piefed.social 2 points 2 hours ago

Sort of, but each of them uses a different way of making the repository, so really it's more a case of different repositories in different directories, but they can all be on the same website.

[–] gastroglizzy@piefed.social 0 points 3 hours ago

All of that sounds unintuituve and complicated, which I think is the main complaint overall.

[–] DevDave@piefed.social 10 points 9 hours ago (2 children)

i guess the problem with that is having to maintain the repository setup. they're basically web servers with signed files.

That does solve one problem at the cost of a bunch of other potential problems.

[–] woelkchen@lemmy.world 4 points 2 hours ago

I don't see the problem. For years I've used the public Open Build Service instance at openSUSE to package and publish software for openSUSE and Fedora (never cared for Debian/Ubuntu because I packaged the software only for my own use but it's possible).

[–] notabot@piefed.social 4 points 7 hours ago

You can put the repositories on pretty much any static hosting. I haven't tried it, but I'm pretty sure that, with a bit of fiddling, you could even put them on a github pages site.

Both distros have good tooling for maintaining repositories, and I'd say it's probably easier than getting your package into the official repos and keeping it updated there, especially on distros like Debian which favour stability over having the latest versions of packages.

No distribution system is going to be entirely friction free for the author, but I've not encountered any significant issues hosting deb or rpm repos.

[–] Eldritch@piefed.world 0 points 7 hours ago (1 children)

I know right? This is literally what flat pack was meant to address. Just package has push it and let any system use it. So it is a little more complicated and another step on top of everything.

[–] notabot@piefed.social 3 points 6 hours ago (1 children)

To be fair, he does address why flatpak isn't really suitable for his package in particular, as it needs to get out of the sandbix flatpak puts it in, which is hacky. None-the-less, it does feel like he's making a mountain out of a mole hill.

[–] Eldritch@piefed.world 1 points 6 hours ago

Ah that's fair yeah. It's getting better. But without some sort of system where a flat pack can request the permissions that it needs at install or runtime. It's far from where it should be. Trivial to do with an app like flat seal. But that's not typically installed out of the box. It's all command line by default and very obtuse to the average user.

[–] moonpiedumplings@programming.dev 4 points 6 hours ago (1 children)

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.

[–] smiletolerantly@awful.systems 1 points 2 hours ago

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"

[–] Wispy2891@lemmy.world 17 points 10 hours ago (1 children)

I love how he literally packages for any system EXCEPT snap

[–] Eldritch@piefed.world 2 points 7 hours ago (1 children)

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

[–] lemmydividebyzero@reddthat.com 1 points 4 hours ago

They already support many repos. Adding Snap does not make it worse for the others.

[–] jaybone@lemmy.world 1 points 7 hours ago (1 children)

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.

[–] woelkchen@lemmy.world 1 points 2 hours ago

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.

[–] arran4@aussie.zone 1 points 8 hours ago

https://goreleaser.com/ does Rust now.. But it's binary focused but probably what the guy is doing..

For go Debian has: https://go-team.pages.debian.net/ I would imagine there is something similar for rust?

Being open source helps a lot, however he should probably source help for each distro. He is right that it's a pain but I'm not sure his reasons are.