5 ms·

> By trying to shoehorn node/go modules into Debian packages we are creating busy work with almost no value. Another problem, at least with python I've encount

> By trying to shoehorn node/go modules into Debian packages we are creating busy work with almost no value. Another problem, at least with python I've encountered this, is that the debian packages sometimes seem to fight what you downloaded via pip. It's not made to work together. I'm not a python dev so it was very confusing to figure out what is going on, and I wouldn't be surprised if it would be similar if you mix npm and deb packages for js libs. They don't know of each other and can't know which libs were anyway provided by the other, then search paths are unknown to the user etc. I think I went through similar pain when I had to get some ruby project going. My gut feeling is that it would be best if debian only supplied the package of the software in question and let's the "native" dependency management tool handle all the libs, but I guess that would get the debian folks the feeling of loss of control, as it indeed makes it impossible to backport a fix for specific libs; rather you'd have to fiddle with the dependency tree somehow.

initplus 6y ago
Sure they may have to fiddle with the dependency tree, but Node & Go both have well defined dependency formats (go.mod, package.json). It should be relatively easy to record the go.mod/package.json when these applications are built, and issue mass dependency bump & rebuilds if some security issue comes up. Really seems like the best of both worlds, and less work than trying to wrangle the entire set of node/go deps & a selection of versions into the Debian repos. I mean Debian apparently has ~160,000 packages, while npm alone has over 1,000,000!
- erik_seaberg 6y ago
  > mass dependency bump That’s not an option for Debian stable. They intentionally backport security and stability patches, and avoid other changes that might break prod without a really good reason. https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1 https://www.debian.org/doc/manuals/debian-faq/choosing.en.ht...
  - initplus 6y ago
    The situation with backporting security fixes is still the same. Debian could backport the fix to any node/go lib the same way they backport security fixes to C libs. The only difference is that a backported fix in a language that uses vendored dependencies rather than .so's needs to have all depending packages rebuilt.
    - debiandev 6y ago
      Debian Developer here. Backporting fixes to tenths of thousands of packages is already a huge amount of (thankless) work. But it's still done - as long as there's usually one version of a given library in the whole archive. Imagine doing that for e.g. 5 versions of a given library, embedded in the sources of 30 different packages.
      - hackmiester 6y ago
        I'm sorry to hear that it's thankless. Thank you for doing it. It is one of the pillars of my sanity, and I am not exaggerating.
viraptor 6y ago
> the debian packages sometimes seem to fight what you downloaded via pip It's a bit annoying, but there are simple rules and it applies to pip/gem/npm the same (not sure about go): For each runtime installation you have a place for global modules. If you installed that runtime from a system package, you don't touch the global modules - they're managed using system packages. If you install the language runtime on a side (via pyenv, asdf or something else) or use a project-space environment (python venv, bundler, or local node_modules) you can install whatever modules you want for that runtime without conflicts.
- pydry 6y ago
  This is simple but completely counterintuitive. I've seen it go wrong hundreds of times and has been subject to a bunch of different workarounds (e.g. pipx). Debian should probably ship a separate global python environment for Debian packages that depend on python where it is managing the environment - one with a different name (e.g. debpy), a different folder and, preferably, without pip even being available so that it's unlikely people will accidentally mess with it. This could have isolated the python 2 mess they had for years also, de coupling the upgrade of the "python" package from the upgrade of all the various Debian things that depended on python 2. really, it's easier to make "apt install python" be the way to install python "on the side".
  - viraptor 6y ago
    > without pip even being available so that it's unlikely people will accidentally mess with it. This has already happened. It only resulted in lots of "ubuntu broke pip" posts rather than understanding why that happened. (the fact it's not entirely separate from venvs didn't help) But considering that issue, imagine what would happen for people running `apt install python` and not being able to run `python` or `virtualenv`. Most setup guides just wouldn't apply to debian/ubuntu and they can't afford that.
    - pydry 6y ago
      Yeah, of course it did! That's why my primary suggested fix wasn't "just removing pip" but hiving the Debian managed python environment off somewhere different and calling it something else and with different binary names (e.g. debsyspython) that debian package authors could rely upon. Then the default "python" and "pip" could be without debian dependencies and users could go wild doing whatever the hell they want without messing up anything else in the debian dependency tree (like they would with pyenv or conda).
rubyn00bie 6y ago
Can’t you just use “update-alternatives” to set the versions you want? https://wiki.debian.org/DebianAlternatives https://wiki.debian.org/DebianAlternatives

initplus 6y ago

Sure they may have to fiddle with the dependency tree, but Node & Go both have well defined dependency formats (go.mod, package.json). It should be relatively easy to record the go.mod/package.json when these applications are built, and issue mass dependency bump & rebuilds if some security issue comes up. Really seems like the best of both worlds, and less work than trying to wrangle the entire set of node/go deps & a selection of versions into the Debian repos. I mean Debian apparently has ~160,000 packages, while npm alone has over 1,000,000!

erik_seaberg 6y ago
> mass dependency bump That’s not an option for Debian stable. They intentionally backport security and stability patches, and avoid other changes that might break prod without a really good reason. https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1 https://www.debian.org/doc/manuals/debian-faq/choosing.en.ht...
- initplus 6y ago
  The situation with backporting security fixes is still the same. Debian could backport the fix to any node/go lib the same way they backport security fixes to C libs. The only difference is that a backported fix in a language that uses vendored dependencies rather than .so's needs to have all depending packages rebuilt.
  - debiandev 6y ago
    Debian Developer here. Backporting fixes to tenths of thousands of packages is already a huge amount of (thankless) work. But it's still done - as long as there's usually one version of a given library in the whole archive. Imagine doing that for e.g. 5 versions of a given library, embedded in the sources of 30 different packages.
    - hackmiester 6y ago
      I'm sorry to hear that it's thankless. Thank you for doing it. It is one of the pillars of my sanity, and I am not exaggerating.

viraptor 6y ago

> the debian packages sometimes seem to fight what you downloaded via pip It's a bit annoying, but there are simple rules and it applies to pip/gem/npm the same (not sure about go): For each runtime installation you have a place for global modules. If you installed that runtime from a system package, you don't touch the global modules - they're managed using system packages. If you install the language runtime on a side (via pyenv, asdf or something else) or use a project-space environment (python venv, bundler, or local node_modules) you can install whatever modules you want for that runtime without conflicts.

pydry 6y ago
This is simple but completely counterintuitive. I've seen it go wrong hundreds of times and has been subject to a bunch of different workarounds (e.g. pipx). Debian should probably ship a separate global python environment for Debian packages that depend on python where it is managing the environment - one with a different name (e.g. debpy), a different folder and, preferably, without pip even being available so that it's unlikely people will accidentally mess with it. This could have isolated the python 2 mess they had for years also, de coupling the upgrade of the "python" package from the upgrade of all the various Debian things that depended on python 2. really, it's easier to make "apt install python" be the way to install python "on the side".
- viraptor 6y ago
  > without pip even being available so that it's unlikely people will accidentally mess with it. This has already happened. It only resulted in lots of "ubuntu broke pip" posts rather than understanding why that happened. (the fact it's not entirely separate from venvs didn't help) But considering that issue, imagine what would happen for people running `apt install python` and not being able to run `python` or `virtualenv`. Most setup guides just wouldn't apply to debian/ubuntu and they can't afford that.
  - pydry 6y ago
    Yeah, of course it did! That's why my primary suggested fix wasn't "just removing pip" but hiving the Debian managed python environment off somewhere different and calling it something else and with different binary names (e.g. debsyspython) that debian package authors could rely upon. Then the default "python" and "pip" could be without debian dependencies and users could go wild doing whatever the hell they want without messing up anything else in the debian dependency tree (like they would with pyenv or conda).

rubyn00bie 6y ago

Can’t you just use “update-alternatives” to set the versions you want? https://wiki.debian.org/DebianAlternatives https://wiki.debian.org/DebianAlternatives