[Pkg-javascript-devel] Bug#794890: Bug#794890: npm: new upstream version

[Jérémy Lal]

Thank you for tackling the issue. See my answer below.

2016-11-23 14:18 GMT+01:00 Michael Prokop <mika at debian.org>:
> Disclaimer: I'm not blaming nor pointing to anyone, but I feel like
> that this is yet again the team pattern and I'd really like to see
> whether we have any way out of this...
>
> * Jérémy Lal [Tue Nov 15, 2016 at 11:27:02PM +0100]:
>
>> > Is really no one from the Debian Javascript Maintainers working on
>> > the npm packaging or interested in having an up2date version
>> > available for stretch? Are there any known blockers?
>
>> Besides "takes a lot of time", no.
>> The amount of work needed to complete that task is simply discouraging :( Help !
>
> I looked into it and as Paolo mentioned in this bugreport (see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794890#44) many
> new packages would have to be packaged to get a newer npm package
> into Debian. But it seems to also require updating *existing*
> packages. Looking at e.g. the current state of the node-request
> dependency (~2.78.0):
>
> % rmadison node-request
> node-request | 2.26.1-1      | stable          | source, all
> node-request | 2.26.1-1      | stable-kfreebsd | source, all
> node-request | 2.26.1-1      | testing         | source, all
> node-request | 2.26.1-1      | unstable        | source, all

I know it's just an example, but i started working on updating
node-request last week.


> ... I'm afraid the situation of node-* packages in Debian is worse
> than I expected. node-request's upstream release of version 2.26.1
> dates back to August 2013 and nowadays upstream is at version 2.79.
> There's #844072 against node-request (where someone is asking for a
> newer version of node-request in Debian), but it was filed just this
> month (November 2016) and between 2013 and 2016 there was not a
> single package upload for node-request in Debian.
>
> Asking around what other Debian contributors and users usually do when
> they've to deal with npm + nodejs: either "npm install -g npm"(sic!)
> and then use npm to install the actual node packages or directly
> head towards upstream (like https://deb.nodesource.com/setup_4.x).
>
> Now one reason why we have node-* packages in Debian is that they
> are dependencies of further packages. To have some numbers: I see
> 601 packages named "node-*" in sid/amd64 as of today, and when
> looking at their reverse dependencies I see only those 24 binary
> packages with node-* packages in their depends/recommends/suggests:
>
> * chai
> * cleancss
> * emscripten
> * flightgear-phi
> * fonts-font-awesome
> * gis-osm
> * groovebasin
> * grunt
> * jison
> * lava-dev
> * libjs-jquery-ui-docs
> * libjs-util
> * libjs-validator
> * livescript
> * mocha
> * nikola
> * npm
> * npm2deb
> * python-livereload
> * python-webassets
> * python3-livereload
> * python3-webassets
> * twitter-recess
> * ycmd
>
> Reducing it to dependencies only (no recommends or suggests) we
> seem to have only those 18 packages left:
>
> * chai
> * cleancss
> * emscripten
> * flightgear-phi
> * fonts-font-awesome
> * groovebasin
> * grunt
> * jison
> * lava-dev
> * libjs-jquery-ui-docs
> * libjs-util
> * libjs-validator
> * livescript
> * mocha
> * npm
> * npm2deb
> * twitter-recess
>
> [JFTR: I didn't consider and look into build-depends for my numbers
> and didn't verify my list with UDD or similar yet. If my numbers are
> wrong please correct me.]
>
> I might be wrong (please correct me), but my impression is that
> people are uploading node-* packages mainly to satisfy a
> (build-)dependency they have in a package and then don't really care
> about those packages any longer. I also count 196 node-* packages
> without *any* rdepends on them (http://paste.grml.org/2868/ is the
> full list), aren't people working on those things interested in an
> up2date npm package?

I believe as well it is true for most of them.
Bundling dependencies (only when upstream actually takes care of
updating them when doing a release) would solve the issue in many ways.

> Back to the npm situation: I was reporting
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794890#34 because
> Debian's npm can't be really used reliably nowadays (the
> "@module/names" not supported at all). Looking through the
> bugreports of the npm package I'd call it unmaintained, there's even
> an open CVE (https://security-tracker.debian.org/tracker/CVE-2016-3956).
> The last upload was in 2014 and no one felt to call for help with
> its packaging since then (especially now with stretch freeze on our
> horizon), orphan the package etc. or am I missing something here?
>
> Overall, I'm not sure we are providing our users something good with
> the current situation. Though what realistic options do we have get
> forward here? Any thoughts?

Most, if not all, npm dependencies are shipped by upstream "bundled",
meaning they actually take care of updating the dependencies when
doing a release of npm.
That means it would be maintainable (and certainly much easier to do so)
by simply distributing all the bundled submodules as part of the npm
debian package - and by considering the release tarball to be the one
distributed on upstream website, and not the one tagged from the git repository.

If ftp masters are all right with this, i'm willing to do the work.

A question is left open: should the npm package "Provides" all those submodules
and install them to be used by everyone ? Or should it keep them for its own
internal use ?
If bundled submodules are listed in "Provides", it would allow sharing common
code and avoid multiple software to use different copies - i suppose it would be
a good thing, though a bit out of policy.

Jérémy