5 ms·

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

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

lmm 3y ago
> 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.
- mrweasel 3y ago
  > 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.
  - michaelt 3y ago
    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.
    - TrickardRixx 3y ago
      Are venvs not part of stock Python dependency management?
    - rcxdude 3y ago
      conda is now primarily a way to fuck up a python environment, at least in the hands of most useres.
      - lmm 3y ago
        The same is equally true of almost every python dependency management tool.
  - josephg 3y ago
    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?
        3y ago
paldepind2 3y ago
> 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.
- zozbot234 3y ago
  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.
- mrweasel 3y ago
  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.
duped 3y ago
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.

lmm 3y ago

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

mrweasel 3y ago
> 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.
- michaelt 3y ago
  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.
  - TrickardRixx 3y ago
    Are venvs not part of stock Python dependency management?
  - rcxdude 3y ago
    conda is now primarily a way to fuck up a python environment, at least in the hands of most useres.
    - lmm 3y ago
      The same is equally true of almost every python dependency management tool.
- josephg 3y ago
  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?
      - 3y ago

paldepind2 3y ago

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

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

duped 3y ago

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.