* 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>:

> > 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.

Hej :)

> > 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.

Ok, should we Cc ftpmasters@ (and possibly security@)?

> 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.

Good question, I don't really have an opinion on that.

Thanks for fast response, looks like we're sharing much of the same view. :)


Attachment: signature.asc
Description: Digital signature

Pkg-javascript-devel mailing list

Reply via email to