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.
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.
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?
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.
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.
> 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.
The whole point of a stable release is to be, well, stable.
People want to be able to develop their things they need, such as their organization's website, online store, internal email system, support system, and things like that, deploy them, and then get on with doing whatever the organization was organized to do.
They don't want to have to be constantly fiddling with all those things to keep them working. They want to build them, deploy them, and then not have to spend much effort on them until they want to add new features.
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.
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.
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.
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.
