3 ms·

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

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.

yjftsjthsd-h 3y ago
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.
- curt15 3y ago
  What if I want to develop applications using the latest dependency versions on a stable system? Are flatpak/docker/podman the recommended solutions?
  - tremon 3y ago
    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).
    - josephg 3y ago
      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.
      - tremon 3y ago
        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 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.
        josephg 3y ago
        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.
mistrial9 3y ago
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.
- josephg 3y ago
  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.
tremon 3y ago
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.

yjftsjthsd-h 3y ago

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.

curt15 3y ago
What if I want to develop applications using the latest dependency versions on a stable system? Are flatpak/docker/podman the recommended solutions?
- tremon 3y ago
  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).
  - josephg 3y ago
    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.
    - tremon 3y ago
      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 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.
      - josephg 3y ago
        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.

mistrial9 3y ago

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.

josephg 3y ago
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.

tremon 3y ago

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.