5 ms·

I don‘t understand why debian wants to package nodejs libraries? There is already a package manager for nodejs. Why do they have to package it again? The same a

by tpetry 6y ago

I don‘t understand why debian wants to package nodejs libraries? There is already a package manager for nodejs. Why do they have to package it again? The same applies for php or python libraries, both ecosystems do have their own package managers.

hashmush 6y ago
They're talking about "application projects" which I understood as actual programs, not libraries. As a user I don't care if the tools I'm using are written in C, Python or JS, so I shouldn't have to remember which package manager to use, Debian should include them all.
erik_seaberg 6y ago
They don’t want twenty .deb node apps to depend on twenty different versions of the same library, because backporting security fixes to each of them years from now could be a nightmare.
- nikisweeting 6y ago
  Why is Debian responsible for backporting security fixes for the thousands of deb packages available? Shouldn't that responsibility be handed to the package authors/maintainers themselves?
  - scbrg 6y ago
    Debian are the package maintainers.
    - nikisweeting 6y ago
      Right, and therein lies the rub. Unless Debian wants to "boil the ocean" and burn a ludicrous amount of effort on repackaging every last npm and pip package for Debian, that position seems unsustainable long-term. I'm of the opinion that Debian should create more distribution channels (that are available by default) where they are not the maintainers, and old releases are not forced to stay patched in order to remain installable.
  - sigotirandolas 6y ago
    If I understand correctly, Debian decides to deliver a certain version of a package (say v1.2.3) for a certain Debian version and they generally keep that version of the package fixed (or try to stay 100% compatible with it), minus security/major impact bugs which get backported. By doing this, Debian can ensure that when you upgrade the system, nothing breaks. While it's not uncommon for upstreams to offer a stable or LTS channel that mostly works like this (and generally stable distributions decide to package this version), the whole value of Debian is to offer a layer on top of many upstreams with different speeds / practices / release policies / etc. and offer you a system that works well together and doesn't break. So the work/backports they need to do is mostly related to different upstreams working differently or in a way that doesn't allow Debian to stay pinned on a certain version.
  - debiandev 6y ago
    Debian Developer here: upstream developer almost never care to prepare fixes for existing releases.
    - symlinkk 6y ago
      If an upstream dev isn’t supporting software anymore maybe the users should stop using it?
      - tzs 6y ago
        Here's the problem. Say I develop program/library/whatever Foo. I make a new release every six months, so we have Foo 1, six months later Foo 2, six months after that Foo 3, and so on. Between the time Foo n and Foo n+1 are released, I'll release minor updates to Foo n to fix bugs, and maybe even add minor features, but I don't make breaking changes. Foo n+1 can have break changes, and once Foo n+1 is out I stop doing bug fixes on Foo n. My policy is that once Foo n+1 is out, Foo n is frozen. If Foo n has a bug, move to Foo n+1. A new version of Debian comes out, and includes Foo n which is the current Foo at the time. Debian supports new versions for typically 3 years, and the Debian LTS project typically adds another 2 years of security support on top of that. That version of Debian is not going to update to Foo n+1, n+2, n+3, etc., as I release them, because they have breaking changes. A key point of Debian stable is that updates don't break it. That means it is going to stay on Foo n all 3 years, and then for the 2 after that when the LTS project is maintaining it. That means that Debian and later Debian LTS ends up backporting security fixes from Foo n+1 and later to Foo n.
        symlinkk 6y ago
        > Debian supports new versions for typically 3 years, and the Debian LTS project typically adds another 2 years of security support on top of that. I don’t think Debian should try to do this. They should just ship whatever the current release of upstream is. Or better yet, just allow upstream to ship directly to users.
        tzs 6y ago
duskwuff 6y ago
> Why do they have to package it again? Many of those package managers -- like npm and pip -- will require a compiler toolchain to build/install packages with native code components, like packages that bind against C libraries. That isn't an acceptable requirement.
marcthe12 6y ago
Apps. They have distribute bunch of tools written in does language. For example an electron app for nodejs. On top of that bunch language PKG manager are not made for final distribution, mainly for development. Pip does not have an uninstall. This is worse in Lang's like rust, go, Haskell, nodejs where ecosystem design is not really compatible policy of these distros. And rust and nodejs comes in wierd locations so it can eventually needed in base system.

by tpetry 6y ago

hashmush 6y ago

They're talking about "application projects" which I understood as actual programs, not libraries. As a user I don't care if the tools I'm using are written in C, Python or JS, so I shouldn't have to remember which package manager to use, Debian should include them all.

erik_seaberg 6y ago

They don’t want twenty .deb node apps to depend on twenty different versions of the same library, because backporting security fixes to each of them years from now could be a nightmare.

nikisweeting 6y ago
Why is Debian responsible for backporting security fixes for the thousands of deb packages available? Shouldn't that responsibility be handed to the package authors/maintainers themselves?
- scbrg 6y ago
  Debian are the package maintainers.
  - nikisweeting 6y ago
    Right, and therein lies the rub. Unless Debian wants to "boil the ocean" and burn a ludicrous amount of effort on repackaging every last npm and pip package for Debian, that position seems unsustainable long-term. I'm of the opinion that Debian should create more distribution channels (that are available by default) where they are not the maintainers, and old releases are not forced to stay patched in order to remain installable.
- sigotirandolas 6y ago
  If I understand correctly, Debian decides to deliver a certain version of a package (say v1.2.3) for a certain Debian version and they generally keep that version of the package fixed (or try to stay 100% compatible with it), minus security/major impact bugs which get backported. By doing this, Debian can ensure that when you upgrade the system, nothing breaks. While it's not uncommon for upstreams to offer a stable or LTS channel that mostly works like this (and generally stable distributions decide to package this version), the whole value of Debian is to offer a layer on top of many upstreams with different speeds / practices / release policies / etc. and offer you a system that works well together and doesn't break. So the work/backports they need to do is mostly related to different upstreams working differently or in a way that doesn't allow Debian to stay pinned on a certain version.
- debiandev 6y ago
  Debian Developer here: upstream developer almost never care to prepare fixes for existing releases.
  - symlinkk 6y ago
    If an upstream dev isn’t supporting software anymore maybe the users should stop using it?
    - tzs 6y ago
      Here's the problem. Say I develop program/library/whatever Foo. I make a new release every six months, so we have Foo 1, six months later Foo 2, six months after that Foo 3, and so on. Between the time Foo n and Foo n+1 are released, I'll release minor updates to Foo n to fix bugs, and maybe even add minor features, but I don't make breaking changes. Foo n+1 can have break changes, and once Foo n+1 is out I stop doing bug fixes on Foo n. My policy is that once Foo n+1 is out, Foo n is frozen. If Foo n has a bug, move to Foo n+1. A new version of Debian comes out, and includes Foo n which is the current Foo at the time. Debian supports new versions for typically 3 years, and the Debian LTS project typically adds another 2 years of security support on top of that. That version of Debian is not going to update to Foo n+1, n+2, n+3, etc., as I release them, because they have breaking changes. A key point of Debian stable is that updates don't break it. That means it is going to stay on Foo n all 3 years, and then for the 2 after that when the LTS project is maintaining it. That means that Debian and later Debian LTS ends up backporting security fixes from Foo n+1 and later to Foo n.
      - symlinkk 6y ago
        > Debian supports new versions for typically 3 years, and the Debian LTS project typically adds another 2 years of security support on top of that. I don’t think Debian should try to do this. They should just ship whatever the current release of upstream is. Or better yet, just allow upstream to ship directly to users.
        tzs 6y ago

duskwuff 6y ago

> Why do they have to package it again? Many of those package managers -- like npm and pip -- will require a compiler toolchain to build/install packages with native code components, like packages that bind against C libraries. That isn't an acceptable requirement.

marcthe12 6y ago

Apps. They have distribute bunch of tools written in does language. For example an electron app for nodejs. On top of that bunch language PKG manager are not made for final distribution, mainly for development. Pip does not have an uninstall. This is worse in Lang's like rust, go, Haskell, nodejs where ecosystem design is not really compatible policy of these distros. And rust and nodejs comes in wierd locations so it can eventually needed in base system.