Hacker News Reader

I think that there is a good reason to keep those projects in the main distribution: it makes them more robust and prevents the build systems and bootstrapping process from becoming a massive pile of technical debt.

For example, in order to get clojure 10 running on Gentoo I had to go dig through the git history to figure out where spec-alpha and core-specs-alpha and clojure itself did not form a circular dependency in maven. Because clojure was not being packaged in a variety of ways, they now are at risk of making maven central a hard dependency, which makes the whole project less robust.

Do you mean "robust for people using Gentoo" or "robust for everybody"? Isn't the latter responsibility of the Clojure developers rather than packagers?

Robust for everyone. In theory it is the responsibility of the Clojure devs, but if there isn't a packaging workflow that they are aware of, how can they be expected to integrate with it and make design and development decisions that it would reveal to them? The point is more that, the greater variety of different environments a piece of software runs in the more likely it is that systematic weaknesses will be revealed, sort of like chaos engineering, except for whole environments instead of sporadic failures.

Yes packaging for different distributions can reveal unknown problems or enhancement possibilities in the project, however I would be surprised if the developers in general were interested at all in supporting that activity. Maybe Clojure is, I don't know.

Packaging is beneficial mainly to users, I expect developers to choose single platform and support that, if there is more, great. But most developers aren't interested in a massive distraction that accomodating 520+ distributions is.

You're making a distinction between "packagers" and "users" which does not exist. Packagers are advanced users that take the initiative to improve their distro when they find software they want to use and that isn't integrated in their distro.

> Let the new complicated juggernaut software be deployed and configured by the users, according to developers' instructions, using whatever modern mechanism they prefer

I'm not sure what "they" refers to here (developers or users). The existence of packagers is proof that some subset of users "prefer" that software "be deployed and configured" via distro package managers.

I meant ordinary users should rely on developers' defaults. If the user is advanced enough, he will be able to go his own way.

Yes I prefer the package manager too, when it works and gives me what I want. But for the software that changes fast, like new languages / compilers, or juggernaut software like Kubernetes, packagers can't keep up and I do not expect them to.

> The existence of packagers is proof that some subset of users "prefer" that software "be deployed and configured" via distro package managers.

Not necessarily. It might be inertia - back when linux distributions started being organised this way, those language dependency management mechanisms pretty much didn't exist.

CPAN exists since 1993, online since 1995. CPAN has the package manager, which is able to install perl software with their dependencies. It's not a new, unknown technology.

If you are sure that you can create functional, stable, bug free, hole free, up to date, full of useful software distro with 10 independent package managers instead of one, then just do it. We will enjoy it. You will spend about 10x more time than current maintainers, but your time is free, so it's not a problem. Of course, we will say huge THANK YOU for your incredible effort, with nine zeroes after initial zero, except for some hatters, which will blame your perfect distro at HN for no reason.

Debian in particular put a fair bit of effort into integrating apt deeply with CPAN so that you could install a package from there that depended on system libraries and vice versa, and then for subsequent languages they... didn't. You'd think these were well-known technologies, but as far as linux distribution maintaners are concerned they're new and scary.

> If you are sure that you can create functional, stable, bug free, hole free, up to date, full of useful software distro with 10 independent package managers instead of one, then just do it.

I'd rather leave the distribution model behind entirely. And you know what? I do, and it works great. You just get the occasional complaint like this article, but it doesn't actually matter in the real world.

> basic desktop

I actually wish this is feasible, but it isn't. GNOME is basic desktop, GNOME includes librsvg, librsvg build-depends on Rust. So you need to package Rust (hence LLVM) to have GNOME. Your proposal only works if "core OS" refuses to use Rust.

Yeah I get that. GNOME is a horrible big software. I would not count is as "basic desktop", because it is so big, buggy and dependencies are out of control. Basic desktop, I mean something like Xfce, with modular components and minimal dependencies so the desktop system is simple and unixy. You would still have the option to install GNOME on such a system, if only GNOME developers made a canonical version of GNOME that would be modular, and would install on any clean Linux system with Xorg or Wayland.

I think it's likely that there will be "system Rust" which is used to compile libraries used by the OS, but this is independent of the toolchain and crates that most developers use for their own development.

In a binary distribution, you don't necessarily need to install the system toolchain, unless you want to work on the system.

This is why I think the snap store is going the right direction. My web browser and my kernel don't need the same level of attention.

That's literally what windows does, for the most part, actually.

It's the pragmatic thing to do, and it's defacto what happens on Linux distros too. Distros offer pip/docker/cargo, but when some libraries/programs are popular enough, someone will inevitably package it and offer it in a 3rd party repo or the main distro repo. Examples of this would be numpy, ripgrep etc..

Exactly. When you want to install one of those fast-paced pieces of software on your system, you're often dissatisfied with the old version coming with your OS anyway.

I see no problem to bump versions of a few packages, rebuild them, and install them via system package manager. Are you developer or user? Of course, some software may not work after that, but package manager newer stays in your way, unless you have no idea how to use it.

I'm a software developer and a user of package managers. A package manager that allows me to only have one version of a software package installed will inevitably get in my way if I need two programs that need different, incompatible versions of that dependency. It happens quite a lot in my experience.

Basically, you want to put two versions of the same file(s) into one file.

If you need two versions of almost same set of files, then chose different name for the package, e.g. package-2, chose different base directory for package files, e.g. /usr/share/package-2, and chose different names for binaries, e.g. /usr/bin/binary-2. It's not a magic. Just look at examples, e.g. python2 and python3.

But I'm not the author of those packages. How does the package manager allow me to rename existing packages?

You can create your own repository, where you will be maintainer of your packages.

You can use it locally, as directory on disk, or you can put it on a server and share with others, or you can compile it using openSUSE Build Service, which supports OpenSuSE, SLE, Fedora, RedHat, CentOS, Debian, Arch, etc.: https://en.opensuse.org/openSUSE:Build_Service_supported_bui...

To some extent you can do it with snap. https://snapcraft.io/blog/parallel-installs-test-and-run-mul...

A lot of discussion here is already solved by snap/flatpack.

Agreed, and this is basically the model that macOS / Windows have followed since the dawn of time.