Hacker News Reader

Comment by lmm | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com