Hacker News Reader

Comment by viraptor | Hacker News Reader

> and repackage it for their distribution

There's no "re" in there. They decide how to package it for their distribution. The idea that you can take something non-trivial and just install it without issues across multiple systems is flawed. There's a lot of work involved in getting things to work together correctly. (If you don't think that's true, see how many of the current 4k broken packages can you fix in nixos https://hydra.nixos.org/jobset/nixpkgs/trunk )

Upstream software often has assumptions about how things work in your system. It's often not correct.

> But there's a large ecosystem of software that you can get this way that no longer requires packaging up.

Making non-trivial things work correctly in docker, snap, or flatpak is packaging. You effectively still target a specific distribution with a specific setup. It takes work, it takes maintenance, and it likely will degrade over time as your host changes as well.

View on HN

I'm not arguing that packaging shouldn't be done but that it should be done, and is in fact commonly done by upstream developers. What things like docker, snap and flatpak allow is packaging things up in a distribution independent way. Which means it can be done by the developers of the software directly. Of course the landscape is a bit fragmented and you could also see this as yet another package variety to support and there is the usual bit of tribalism around which to use and not to use. But overall, it means a lot of software is now available that you would in the past have had to install via distribution specific packages.

Then the much better cause to fight for is to make this packaging and installing not resemble splattering a bucket of paint on the wall (installing stuff in /usr, /bin, /etc and so forth).

The Linux distros did a good job packaging stuff but in the end it's all a very wasted effort that should have gone to unifying the way stuff is installed so we could all be more productive after.

I can dream, I know. Some people will likely pull out a gun if you say that /usr/bin should exist only as a collection of symlinks.

> The idea that you can take something non-trivial and just install it without issues across multiple systems is flawed

Why? If anything, the fact that you can't is the real flaw

Some examples I fixed just this week:

- feature name changed, feature autodetection fails, package doesn't build anymore

- new version of the package requires a new Apple SDK which is not used by default in the system yet

- SDL gets updated which bumps the minimal required Apple SDK version. The package depending on SDL declares lower minimal SDK which fails at linking

- package requires a specific flag when building with latest GCC, but that flag doesn't exist for clang, so it fails the build

- new C++ standard adds std::bind which breaks unscoped calls to bind. Upstream didn't force an older standard, so build breaks on clang update.

- Makefile makes assumptions about HOME being writable during a build.

- build system assumes where the completion files will go

And those are still the trivial problems. Some of those are fixable upstream, some will be "don't care" for the author or the package is already abandoned. Some exist because the author doesn't have particular hardware to test on. It's on the distributions to make it work for you regardless.

Reply on news.ycombinator.com