Cc-ing ftpmas...@debian.org hereby with a (nearly) fullquote below - it's about #794890 and the situation of the npm package within Debian, we'd appreciate your input/feedback on this matter. Thanks!
regards, -mika- * Jérémy Lal [Wed Nov 23, 2016 at 02:42:23PM +0100]: > 2016-11-23 14:18 GMT+01:00 Michael Prokop <m...@debian.org>: > > 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): [...] > > ... 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.
signature.asc
Description: Digital signature
