Hacker News Reader

Comment by BiteCode_dev | Hacker News Reader

Try to provide a package of a GUI app "for linux". After you support centos, fedora, debian, ubuntu, gentoo and arch, you'll maintain a mess of brittle packaging scripts for years, breaking at each release and some updates. Just making the first release for each is a challenge. Even app images, the least well integrated system will fail at some point.

You'll see how stable is diversity.

Then package for windows xp. It probably works on windows vista, 7, 8 and 10.

Now I do see a lot of value in diversity. Resiliance, ethics, competition, collaboration...

Stability isn't one.

View on HN

If you're actually interested in packaging a generic Linux GUI app, check out snapd. It's originally an Ubuntu project, but has been pretty widely adopted at this point. I believe every distro you mentioned can run snaps, except maybe Gentoo.

https://snapcraft.io/

Snapd has it's own set of problems.

It is sandboxed, so your use case must be compatible.

It uses apparmor, what if the system uses SEL ?

It's sandboxed in a certain way, your app must support it.

It's very recent, only the latest distribs have a snapd release that works well.

It's slower to execute.

Snapd assumes systemd.

But wait, did you say snapd ? I though you said flatpack. Or appimages.

Anyway, despite all that, it is easier to write a snapd instead of a deb+rpm+whatever. I actually like this project a lot.

And again it proves my point: to get stability, we use snapd, a tool to compensate for diversity.

Do developers not know how to statically compile software anymore?

Also, you shouldn't be writing your own packaging scripts: leave those to distribution packagers. There are thousands of people who work on packaging these things, and the user of the distribution is much safer if they don't touch software distributed by random people.

This stuff is completely stable, just don't break the assumptions of the system without knowing what you're doing.

Depending on distributors means that your users will only use ages old versions of your software, thus you receive support requests for stuffprobably already fixed/changed. Sending users back to distros also takes time.

And for static linking: That is kind of happening with those modern snap and flatpack and whatever systems for handling applications, but it's bad for security. I want to update my system zlib in case there is an issue instead if depending on all applications consuming compressed unteusted streams updating their package in time. And I certainly don't want each little tool bundling their own Qt.

Oh, but you still need to make a deb, rpm, nix, whatnot then compose with the os tooling, conventions and expectations. And use those to provide your conf/update/failure, menu integration, permission system, logging, init system, notifications, etc.

Or provide an app image and ignore most integration.

This is my point exactly: to get stability, you remove diversity.

Static linking, one packaging system, and you don't have to care about how diverse the universe it.

But it also means you don't benefit from what make those differences add: security updates, dependancy graph, automation, signing, jails, user documentation and training, os integration, native window theming, etc.

This shouldn't need to be done? The distribution's packagers handle most of this. Except for Nix, maybe? I hear they have a particularly fucked up ecosystem for packaging.

No.

The chances your project matches the criterias to be included into any distrib repo are very low, and it's a lot of work and problems by itself.

They are not app stores you pay to get into. The gate keepers have a very strict opinion on what to let in and how. And it's all done manually, and fedora policy is not debian's is not gentoo's.

Plus, statically linked projects are almost never accepted. Back to square one.

Besides, what if it's not free software ?

> The distribution's packagers handle most of this.

And often fuck it up and introduce bugs or even vulnerabilities, intentionally ignore the developer, or simply fail to update packages in a reasonable time frame.

Relying on free labor to package software for you is a terrible terrible idea that helps keep Linux Desktop a shitshow.

Disagree strongly and as a user I feel distributions and package maintainers are a necessary defense against overly opinionated developers.

I'm glad there is a layer there that will patch and configure to better integrate into the system and in some (very rare) cases remove user hostile "functionality".

Sometimes it's better to trust the developers, not the packagers. Example is the Debian SSH vulnerability from 2008: https://www.debian.org/security/2008/dsa-1576

This was a bug introduced in packaging. See https://lwn.net/Articles/281436/ for more details.

Reply on news.ycombinator.com