Hacker News Reader

Comment by mrweasel | Hacker News Reader

> The Debian model of an artisanal handcrafted build for every library is just not sustainable.

Yet it has functioned for 25 years (apt turned 25 this year). There has been mistakes, like the OpenSSL "fix", but not many. One issue that I, now that you mention Javascript, is stuff like npm, but to me that more a sign of npm being badly broken by design, or at least designed for a different environment. Build Python projects on Debian, using apt as you dependency manager works pretty well for systems that you expect to be stable over time.

One think so seems to forget is that you can often pull in newer versions of libraries and other packages from Backports. That does mitigate some of the issues with packages being to old.

View on HN

> Yet it that functioned for 25 years (apt turned 25 this year).

Up to a point. Even 15 years ago the issues were clear and people were having to work around them.

> There has been mistakes, like the OpenSSL "fix", but not many.

That was the single worst bug in a general-purpose computer system IMO, and a predictable result of the Debian way of building packages. But they never felt the need to change their policies.

> Build Python projects on Debian, using apt as you dependency manager works pretty well

Python has notoriously terrible dependency management. It's a pretty low bar.

> One think so seems to forget is that you can often pull in newer versions of libraries and other packages from Backports. That does mitigate some of the issues with packages being to old.

The fact that there is such a big ecosystem of workarounds for linux distro packaging should tell you there's something fundamentally wrong with the basic idea.

> Python has notoriously terrible dependency management. It's a pretty low bar.

That's subjective. In my mind it's the only one that makes any sort of sense and isn't a freaking nightmare to use.

Some would say the fact that venvs and conda are so widely used shows that many users encounter problems with the stock Python dependency management.

Are venvs not part of stock Python dependency management?

conda is now primarily a way to fuck up a python environment, at least in the hands of most useres.

The same is equally true of almost every python dependency management tool.

As a software developer who’s written a fair bit of code in JavaScript, C and recently Rust, the idea that I would look for my dependencies in apt on Debian is a bad joke. At best I’ll get some ancient version of the things I depend on. But more likely, 2/3rds of the libraries I use simply won’t be there at all. Is the rust compiler in apt? Is serde? Rand? What about the long tail of my programs dependencies?

I remember looking in apt for nodejs one time and the version it had was about 5 years out of date, and it was missing all sorts of quality of life features that I had long since taken for granted (like promises). And of course, half of the packages in npm failed to run at all as a result. It was a complete non starter. Maybe I should have searched apt for ancient versions of common JavaScript libraries from a similar vintage? Then I could install them system wide. Yay. And what would all that extra hassle get me? A JavaScript program that would only work on one crusty Linux distribution. Which is strictly worse than what nodejs ships with out of the box: npm. Up to date packages. Modern JavaScript. And compatibility a mile wide.

And I could tell the same story with rust and cargo, and plenty of other languages.

Apt really makes no sense at all to use in this context. Maybe it’s fine to install X and gvim. But that’s about it.

If Debian really wants to mirror npm and cargo and other languages’ package managers, why don’t they just automate it, and add the hundreds of thousands of packages en masse?

Manually adding specific versions of packages from npm and cargo sounds like a massive waste of human effort. At best it will only ever produce a pale imitation of the real package repositories. I just don’t see the point.

The idea of Debian is to have a stable system that doesn't change if it possibly can for the life of the release. If you want to constantly get new breaking changes in your packages, switch to testing or sid.

What if I want to develop applications using the latest dependency versions on a stable system? Are flatpak/docker/podman the recommended solutions?

If you want the latest dependencies, you don't have a stable system: it shifts with the versions of your dependencies. In Debian, you would use an unstable/sid chroot with the new versions (see debootstrap).

That’s a weird usage of the term “stable”. Is the latest rustc release unstable? Are there bugs in nodejs? It’s been years since a nodejs bug affected me.

If anything you usually have fewer problems with newer toolchains, because new features get used by your dependencies. The version of rustc or nodejs that Debian considers “stable” won’t be able to run a lot of software that I want to run.

And despite the name, “unstable” Debian is still usually 6 months behind the latest version of most packages. That’s an eternity for new things like Zig.

It's the Debian usage of the term "stable". Seems kinda relevant for the discussion, at least to me. From https://wiki.debian.org/DebianStability:

This is what Debian's Stable name means: that, once released, the operating system remains relatively unchanging over time.

> That’s an eternity for new things like Zig

So why isn't Zig making sure that their latest releases are available in Debian Sid? Anyone can be a Debian Maintainer, and if they don't want to invest their time in it, they just need an existing DM to sponsor their uploads.

Yeah it’s relevant. It’s just, not how a lot of software is made today. I don’t want my browser or my compiler to remain unchanged. I want it to be evergreen. Stop updating your web browser and in a year or two websites will stop working properly.

As for why don’t the zig developers become official Debian maintainers, gentoo maintainers, redhat maintainers, FreeBSD maintainers, homebrew maintainers and so on - well, probably because they’re too busy making zig. There are way too many unix package managers to support without help. Especially if doing so requires joining mailing lists, manual testing and so on. I wish there was a way to automate making all those packages across different unix distributions, but I can see why that’s a hard problem.

Short answer: Yes.

Longer answer: In Debian's arrangement, the idea is that the distribution moves together, so it doesn't have a native idea of "fast moving packages on top of slow moving base packages". There are other systems where this isn't the case; AUIU you can run bleeding-edge packages on a stable FreeBSD base system (largely because the BSDs have a very strong separation of the base OS from everything on top), and NixOS is quite happy, especially with flakes but you could do it other ways, to go as far as "start with stable NixOS but then add packages X, Y, Z from unstable, and don't provide libFoo at all in a global context but provide libFoo 1.0 to package A, libFoo 2.1 to package B, and libFoo 3.0g straight from git for package C". But in Debian, the equivalent is probably running a newer version in a chroot or container, yes.

script language development is not a great example for packaging patterns when you compare to the OS itself.

what is the constructive way forward? treat script language development and its packaging in a different way than OS base setup.

What does “script language development” mean? Despite the name, I’m not using JavaScript to write scripts. I’m largely writing networked server applications - which are very much a systems problem.

And rust is very much not a scripting language but it’s in exactly the same boat. Actually it’s probably worse because async and http support isn’t built in to rust’s standard library. A simple hello world web server with tokio and serde will probably have on the order of 40 dependencies in the dependency tree, not to mention rustc and cargo. How many of them do you think are in apt? Maybe none since, contra Debian’s policy, the final build result is statically linked anyway. The rust compiler doesn’t support dynamic linking of rust dependencies.

The reality is that apt simply doesn’t provide a stable, useful, modern software development ecosystem. The task of providing a “stable” version of rustc or nodejs is these days the responsibility of the rust and nodejs projects - which both have CI with incredible testing infrastructure. And the effect of that is that the latest stable versions are going to work more reliably to run real JavaScript and rust programs than whatever crusty version Debian ships.

And that disharmony between what Debian wants and what developers want causes real problems when shipping software to end users, and when deploying software to servers.

Debian is an end-user distribution, not a development tool. It bundles stable versions of software, which it releases at (somewhat) timed intervals. The Debian model of software development means that software developers target testing/sid for their new versions (and work to make sure the dependencies they need are in sid!) so that their software is automatically ready for inclusion when a new release is made.

There's two problems with that: many tools no longer have multiple development lines, which means that Debian can't keep its stable releases secure without manual backporting effort, and upstream developers don't care about getting their software in Debian. This means that Debian unstable already lags behind, as you notice, but also that the freeze-before-release takes longer than necessary. But in my view, those are mainly ecosystem problems, not just Debian problems.

> One issue that I, now that you mention Javascript, is stuff like npm, but to me that more a sign of npm being badly broken by design, or at least designed for a different environment.

npm being "badly broken by design" is one opinion. But the fact is that almost all modern language tooling is moving in the direction of becoming more npm-like or has been created from the beginning with heavy npm inspiration. See for instance Rust's Cargo, Dart's Pub, Go's modules, Python's virtual env, Esy for Ocaml, and more. Developers love being able to easily manage and add dependencies, and this problem is only going to grow for Linux distributions across language ecosystems.

What's "badly broken" is JavaScript development as a whole, and TypeScript provides the closest thing to a workable solution where library upgrades along semver lines can be expected to just work. Python is also a highly dynamic language, but there's also a lot less churn in that ecosystem and this does help to a large extent wrt. packaging libraries for a distribution.

Pythons virtualenv is old than npm. For me, I think what makes Pythons dependency management work for me is that there's a logical separation between the environment and the package managers. You create a new environment, using venv, pyenv, Conda, containers, whatever you like, doesn't matter, then you install packages into that environment, might be latest, might be a specific version, depends entirely on your needs.

Something like npm og Rubys Gem, are confusing because I have no idea where the packages went. Apparently they like somewhere in the current directory, maybe? What if I want to use the same environment and package elsewhere? I'm sure you can do it, but it doesn't seem logical to me that you don't need to specify which environment you're using. It's the same with Go, it's rather confusing where packages go, or which version, it's all squirreled away in the go command. In one way it is really nice that it just goes into the same project directory, but it's also a little confusing that your environment changes when you move directories.

For production and containers... you normally just have that one thing running, so into the global environment it goes and here using apt to install the packages also ensures security updates, well not in the containers perhaps, unless you rebuild them.

> It's the same with Go, it's rather confusing where packages go, or which version, it's all squirreled away in the go command

Something that was lost when we moved to modules - the system is still the same, it's just that if you never used the old system (GOPATH) or read the manual, then you might be confused about where things have gone.

Also of note is that vendoring was for a time Go's answer to dependency management and can still easily be done, and is supported by the tooling.

If you use Ruby with rvm or asdf the gems go in a directory inside your home, named after the ruby version you are using for a given project and possibly a gemset you defined, so two projects with different dependencies but the same ruby don't interfere with each other. Or just use bundle and activate only the gems in the local Gemfile. Or use docker and put everything inside a container.

If I can complain about something is that there are so many ways to do it that I can't remember their details when I'm away from my laptop, as I am now. I think that I have at least one occurrence of all those 4 methods on my laptop, for different customers. They decide and everybody makes a different decision.

Other languages: same problems with different tools.

Or you could do the sane thing that Java/Maven did and have a classpath and have a single local repo and references just to stuff you need, without any conflicts (barring conflicts inherent to any package manager with transitive dependencies).

> Something like npm og Rubys Gem, are confusing because I have no idea where the packages went. Apparently they like somewhere in the current directory, maybe? What if I want to use the same environment and package elsewhere? I'm sure you can do it, but it doesn't seem logical to me that you don't need to specify which environment you're using.

I find the opposite - in theory the Python way might be more orthogonal, but in practice all that does is gives you more chance to shoot yourself in the foot. Realistically I never want to run project A's code in project B's environment or vice versa, and I certainly don't want to update project B's environment with project A's dependencies - combined with the fact that there's no way to undo a `pip install` command or recreate the previous state, you can permanently screw up your development environment by mixing up your terminals.

If it's functioned for 25 years why does no one use it for their ecosystem?

There's a wide range of package managers in the wild that exist to help build software using features that apt fundamentally does not support because of its broken model of the universe.

Reply on news.ycombinator.com