[Buildroot] [PATCH v3 1/1] jsen: new package

[Buildroot] [PATCH v3 1/1] jsen: new package

[Atul Singh]

---
Signed-off-by: Atul Singh <atul.singh.mandla@rockwellcollins.com>
 package/Config.in      |  1 +
 package/jsen/Config.in |  6 ++++++
 package/jsen/jsen.hash |  2 ++
 package/jsen/jsen.mk   | 18 ++++++++++++++++++
 4 files changed, 27 insertions(+)
 create mode 100644 package/jsen/Config.in
 create mode 100644 package/jsen/jsen.hash
 create mode 100644 package/jsen/jsen.mk

diff --git a/package/Config.in b/package/Config.in
index a5b31aa..6f8b8bd 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -984,6 +984,7 @@ menu "External jQuery plugins"
 	source "package/jquery-validation/Config.in"
 endmenu
 endif
+	source "package/jsen/Config.in"
 	source "package/jsmin/Config.in"
 	source "package/json-javascript/Config.in"
 endmenu
diff --git a/package/jsen/Config.in b/package/jsen/Config.in
new file mode 100644
index 0000000..8c41a19
--- /dev/null
+++ b/package/jsen/Config.in
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_JSEN
+	bool "jsen"
+	help
+	  JSEN (JSON Sentinel) validates your JSON objects using JSON-Schema.
+
+	  https://github.com/bugventure/jsen
diff --git a/package/jsen/jsen.hash b/package/jsen/jsen.hash
new file mode 100644
index 0000000..fdfcd93
--- /dev/null
+++ b/package/jsen/jsen.hash
@@ -0,0 +1,2 @@
+# Locally Computed
+sha256  651b3ae5c92865705c144175a8297305788a0e9a1f46ee9b8caa127c6bce6709  jsen-v0.6.0.tar.gz
diff --git a/package/jsen/jsen.mk b/package/jsen/jsen.mk
new file mode 100644
index 0000000..535389d
--- /dev/null
+++ b/package/jsen/jsen.mk
@@ -0,0 +1,18 @@
+################################################################################
+#
+# jsen
+#
+################################################################################
+
+JSEN_VERSION = v0.6.0
+JSEN_SITE = $(call github,bugventure,jsen,$(JSEN_VERSION))
+JSEN_LICENSE = MIT
+JSEN_LICENSE_FILES = LICENSE
+
+define JSEN_INSTALL_TARGET_CMDS
+        mkdir -p $(TARGET_DIR)/usr/share/jsen
+        $(foreach d,dist lib index.js,\
+                cp -dpfr $(@D)/$(d) $(TARGET_DIR)/usr/share/jsen/$(sep))
+endef
+
+$(eval $(generic-package))
-- 
2.5.0

[Buildroot] [PATCH v3 1/1] jsen: new package

[Arnout Vandecappelle]

On 02/23/16 14:24, Atul Singh wrote:
> 
> ---
> Signed-off-by: Atul Singh <atul.singh.mandla@rockwellcollins.com>
>  package/Config.in      |  1 +
>  package/jsen/Config.in |  6 ++++++
>  package/jsen/jsen.hash |  2 ++
>  package/jsen/jsen.mk   | 18 ++++++++++++++++++
>  4 files changed, 27 insertions(+)
>  create mode 100644 package/jsen/Config.in
>  create mode 100644 package/jsen/jsen.hash
>  create mode 100644 package/jsen/jsen.mk
> 
> diff --git a/package/Config.in b/package/Config.in
> index a5b31aa..6f8b8bd 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -984,6 +984,7 @@ menu "External jQuery plugins"
>  	source "package/jquery-validation/Config.in"
>  endmenu
>  endif
> +	source "package/jsen/Config.in"

 I wonder if this is really the correct place for it. This menu is for
Javascript libraries that are installed in /var/www, i.e. that are meant to be
used by web clients. AFAICS, however, jsen is meant to be used with nodejs
(which is why it's installed in /usr/share, I guess). So I think we should
create a new menu under the nodejs package:

	source "package/nodejs/Config.in"
if BR2_PACKAGE_NODEJS
menu "NodeJS libraries/modules"
	source "package/jsen/Config.in"
endmenu
endif

 I vaguely remember that this was discussed before - if so, the conclusion of
that discussion should have been in your commit message.


 Regards,
 Arnout

>  	source "package/jsmin/Config.in"
>  	source "package/json-javascript/Config.in"
>  endmenu
> diff --git a/package/jsen/Config.in b/package/jsen/Config.in
> new file mode 100644
> index 0000000..8c41a19
> --- /dev/null
> +++ b/package/jsen/Config.in
> @@ -0,0 +1,6 @@
> +config BR2_PACKAGE_JSEN
> +	bool "jsen"
> +	help
> +	  JSEN (JSON Sentinel) validates your JSON objects using JSON-Schema.
> +
> +	  https://github.com/bugventure/jsen
> diff --git a/package/jsen/jsen.hash b/package/jsen/jsen.hash
> new file mode 100644
> index 0000000..fdfcd93
> --- /dev/null
> +++ b/package/jsen/jsen.hash
> @@ -0,0 +1,2 @@
> +# Locally Computed
> +sha256  651b3ae5c92865705c144175a8297305788a0e9a1f46ee9b8caa127c6bce6709  jsen-v0.6.0.tar.gz
> diff --git a/package/jsen/jsen.mk b/package/jsen/jsen.mk
> new file mode 100644
> index 0000000..535389d
> --- /dev/null
> +++ b/package/jsen/jsen.mk
> @@ -0,0 +1,18 @@
> +################################################################################
> +#
> +# jsen
> +#
> +################################################################################
> +
> +JSEN_VERSION = v0.6.0
> +JSEN_SITE = $(call github,bugventure,jsen,$(JSEN_VERSION))
> +JSEN_LICENSE = MIT
> +JSEN_LICENSE_FILES = LICENSE
> +
> +define JSEN_INSTALL_TARGET_CMDS
> +        mkdir -p $(TARGET_DIR)/usr/share/jsen
> +        $(foreach d,dist lib index.js,\
> +                cp -dpfr $(@D)/$(d) $(TARGET_DIR)/usr/share/jsen/$(sep))
> +endef
> +
> +$(eval $(generic-package))
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v3 1/1] jsen: new package

[Thomas Petazzoni]

Arnout,

On Tue, 23 Feb 2016 21:44:52 +0100, Arnout Vandecappelle wrote:

>  I wonder if this is really the correct place for it. This menu is for
> Javascript libraries that are installed in /var/www, i.e. that are meant to be
> used by web clients. AFAICS, however, jsen is meant to be used with nodejs
> (which is why it's installed in /usr/share, I guess). So I think we should
> create a new menu under the nodejs package:

Atul originally placed jsen under the Libraries -> JSON/XML, and I
suggested him to put it under the Javascript libraries.

> 	source "package/nodejs/Config.in"
> if BR2_PACKAGE_NODEJS
> menu "NodeJS libraries/modules"
> 	source "package/jsen/Config.in"
> endmenu
> endif

If it's indeed a NodeJS package, then comes the question of how we are
going to package those zillions of modules. Today, one can request any
random NodeJS module to be installed using
BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL (which is simple, but obviously
circumvents completely the download and legal infrastructures of
Buildroot).

Atul, are you using jsen in the context of NodeJS ? If not, in which
context are you using it ?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v3 1/1] jsen: new package

[Jörg Krause]

Arnout, Thomas, Atul,

On Di, 2016-02-23 at 22:04 +0100, Thomas Petazzoni wrote:
> Arnout,
> 
> On Tue, 23 Feb 2016 21:44:52 +0100, Arnout Vandecappelle wrote:
> 
> > 
> > ?I wonder if this is really the correct place for it. This menu is
> > for
> > Javascript libraries that are installed in /var/www, i.e. that are
> > meant to be
> > used by web clients. AFAICS, however, jsen is meant to be used with
> > nodejs
> > (which is why it's installed in /usr/share, I guess). So I think we
> > should
> > create a new menu under the nodejs package:
> Atul originally placed jsen under the Libraries -> JSON/XML, and I
> suggested him to put it under the Javascript libraries.
> 
> > 
> > 	source "package/nodejs/Config.in"
> > if BR2_PACKAGE_NODEJS
> > menu "NodeJS libraries/modules"
> > 	source "package/jsen/Config.in"
> > endmenu
> > endif
> If it's indeed a NodeJS package, then comes the question of how we
> are
> going to package those zillions of modules. Today, one can request
> any
> random NodeJS module to be installed using
> BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL (which is simple, but obviously
> circumvents completely the download and legal infrastructures of
> Buildroot).
> 
> Atul, are you using jsen in the context of NodeJS ? If not, in which
> context are you using it ?

Using BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL should be the only way to
install Node.js modules. Note that npm, the Node.js package manager
takes care of all the package dependencies. In my opinion, this is the
only sane way of installing Node.js modules for now.

About legal infrastructure: for all installed Node.js packages the
package.json file could be searched for the license information.

Best regards
J?rg Krause

[Buildroot] [PATCH v3 1/1] jsen: new package

[Thomas Petazzoni]

Hello,

On Thu, 25 Feb 2016 11:32:17 +0100, J?rg Krause wrote:

> > Atul, are you using jsen in the context of NodeJS ? If not, in which
> > context are you using it ?
> 
> Using BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL should be the only way to
> install Node.js modules. Note that npm, the Node.js package manager
> takes care of all the package dependencies. In my opinion, this is the
> only sane way of installing Node.js modules for now.

Thanks for raising your voice on this patch, it's definitely
interesting to get some feedback. Since I'm not at all a NodeJS guy,
I'm interested in having more details about:

 - Why you think the only sane way is to use
   BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL as opposed to having proper
   packages for the different modules, like we do for the Perl,
   Python and Lua packages ?

 - What solution you propose to properly integrate this with the
   download and legal infrastructure of Buildroot. Right now, having
   "npm install" directly download and install stuff means that the
   download and legal-info infrastructure of Buildroot is completely
   worked-around. Due to this, "make source" will not download all the
   source, "make legal-info" will not list all the licenses, caching in
   BR2_DL_DIR doesn't work, BR2_PRIMARY_SITE doesn't work, etc.

> About legal infrastructure: for all installed Node.js packages the
> package.json file could be searched for the license information.

Yes, but that's not integrated in the legal-info output, and doesn't
solve the download infrastructure integration problem.

At best, what this package.json file could help with, is help creating
a script (much like scancpan) that automatically creates a Buildroot
package for a given npm module.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v3 1/1] jsen: new package

[Jörg Krause]

On Do, 2016-02-25 at 13:51 +0100, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 25 Feb 2016 11:32:17 +0100, J?rg Krause wrote:
> 
> > 
> > > 
> > > Atul, are you using jsen in the context of NodeJS ? If not, in
> > > which
> > > context are you using it ?
> > Using BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL should be the only way
> > to
> > install Node.js modules. Note that npm, the Node.js package manager
> > takes care of all the package dependencies. In my opinion, this is
> > the
> > only sane way of installing Node.js modules for now.
> Thanks for raising your voice on this patch, it's definitely
> interesting to get some feedback. Since I'm not at all a NodeJS guy,
> I'm interested in having more details about:
> 
> ?- Why you think the only sane way is to use
> ???BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL as opposed to having proper
> ???packages for the different modules, like we do for the Perl,
> ???Python and Lua packages ?

Because npm supports version ranges. Have a look at the example from
the npm's docs [1]:

{ "dependencies" :
? { "foo" : "1.0.0 - 2.9999.9999"
? , "bar" : ">=1.0.2 <2.1.2"
? , "baz" : ">1.0.2 <=2.3.4"
? , "boo" : "2.0.1"
? , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
? , "asd" : "http://asdf.com/asdf.tar.gz"
? , "til" : "~1.2"
? , "elf" : "~1.2.3"
? , "two" : "2.x"
? , "thr" : "3.3.x"
? , "lat" : "latest"
? , "dyl" : "file:../dyl"
? }
}

Lets take for example the dependency "boo". A package "A" may depend on
version "2.0.1" whereas another package "B" may depend on version
"2.3.x".

In this case npm installs boo at 2.0.1 in the subdirectory "node_modules"
of package "A" and boo at 2.3.4 (assume 2.3.4 is the most recent version
for 2.3.x) in the subdirectory "node_modules" of package "B":

{prefix}/lib/node_modules?????A
???? ????node_modules
?? ? ? ? ??? boo at 2.0.1
???? B
? ? ???? node_modules
? ? ? ? ???? boo@2.3.4

As Buildroot does not support different versions for most of the
packages I think we should only use npm to install Node.js packages.

> ?- What solution you propose to properly integrate this with the
> ???download and legal infrastructure of Buildroot. Right now, having
> ???"npm install" directly download and install stuff means that the
> ???download and legal-info infrastructure of Buildroot is completely
> ???worked-around. Due to this, "make source" will not download all
> the
> ???source, "make legal-info" will not list all the licenses, caching
> in
> ???BR2_DL_DIR doesn't work, BR2_PRIMARY_SITE doesn't work, etc.

I am not sure for now howto integrate this into the Buildroot
infrastructure properly. I have never thought about this, but it will
need some work to be done, I guess.

> > 
> > About legal infrastructure: for all installed Node.js packages the
> > package.json file could be searched for the license information.
> Yes, but that's not integrated in the legal-info output, and doesn't
> solve the download infrastructure integration problem.
> 
> At best, what this package.json file could help with, is help
> creating
> a script (much like scancpan) that automatically creates a
> Buildroot
> package for a given npm module.

I have never had a look at?scancpan and I am not familiar with Perl
packages, but looking at some META.json files, I guess it could be done
similiar.

Best regards
J?rg Krause

[1]?https://docs.npmjs.com/files/package.json#dependencies

[Buildroot] [PATCH v3 1/1] jsen: new package

[Thomas Petazzoni]

J?rg,

Thanks for your feedback!

On Thu, 25 Feb 2016 15:01:04 +0100, J?rg Krause wrote:

> Because npm supports version ranges. Have a look at the example from
> the npm's docs [1]:
> 
> { "dependencies" :
> ? { "foo" : "1.0.0 - 2.9999.9999"
> ? , "bar" : ">=1.0.2 <2.1.2"
> ? , "baz" : ">1.0.2 <=2.3.4"
> ? , "boo" : "2.0.1"
> ? , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
> ? , "asd" : "http://asdf.com/asdf.tar.gz"
> ? , "til" : "~1.2"
> ? , "elf" : "~1.2.3"
> ? , "two" : "2.x"
> ? , "thr" : "3.3.x"
> ? , "lat" : "latest"
> ? , "dyl" : "file:../dyl"
> ? }
> }
> 
> Lets take for example the dependency "boo". A package "A" may depend on
> version "2.0.1" whereas another package "B" may depend on version
> "2.3.x".

Gaah, this is horrible.

> In this case npm installs boo at 2.0.1 in the subdirectory "node_modules"
> of package "A" and boo at 2.3.4 (assume 2.3.4 is the most recent version
> for 2.3.x) in the subdirectory "node_modules" of package "B":
> 
> {prefix}/lib/node_modules?????A
> ???? ????node_modules
> ?? ? ? ? ??? boo at 2.0.1
> ???? B
> ? ? ???? node_modules
> ? ? ? ? ???? boo at 2.3.4
> 
> As Buildroot does not support different versions for most of the
> packages I think we should only use npm to install Node.js packages.

Well, we can support this by having separate packages, but if they
really break "boo" at every release and we need to package ten
different versions of it, then it's a mess indeed.

> 
> > ?- What solution you propose to properly integrate this with the
> > ???download and legal infrastructure of Buildroot. Right now, having
> > ???"npm install" directly download and install stuff means that the
> > ???download and legal-info infrastructure of Buildroot is completely
> > ???worked-around. Due to this, "make source" will not download all
> > the
> > ???source, "make legal-info" will not list all the licenses, caching
> > in
> > ???BR2_DL_DIR doesn't work, BR2_PRIMARY_SITE doesn't work, etc.
> 
> I am not sure for now howto integrate this into the Buildroot
> infrastructure properly. I have never thought about this, but it will
> need some work to be done, I guess.

If you don't have Buildroot packages, it will be nearly impossible I
believe.

> I have never had a look at?scancpan and I am not familiar with Perl
> packages, but looking at some META.json files, I guess it could be done
> similiar.

We have a similar script being worked on for Python, if you're familiar
with Python. See for example http://patchwork.ozlabs.org/patch/501204/.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v3 1/1] jsen: new package

[Jörg Krause]

Dear Thomas,

sorry for very late reply!

On Do, 2016-02-25 at 17:20 +0100, Thomas Petazzoni wrote:
> J?rg,
> 
> Thanks for your feedback!
> 
> On Thu, 25 Feb 2016 15:01:04 +0100, J?rg Krause wrote:
> 
> > 
> > Because npm supports version ranges. Have a look at the example
> > from
> > the npm's docs [1]:
> > 
> > { "dependencies" :
> > ? { "foo" : "1.0.0 - 2.9999.9999"
> > ? , "bar" : ">=1.0.2 <2.1.2"
> > ? , "baz" : ">1.0.2 <=2.3.4"
> > ? , "boo" : "2.0.1"
> > ? , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
> > ? , "asd" : "http://asdf.com/asdf.tar.gz"
> > ? , "til" : "~1.2"
> > ? , "elf" : "~1.2.3"
> > ? , "two" : "2.x"
> > ? , "thr" : "3.3.x"
> > ? , "lat" : "latest"
> > ? , "dyl" : "file:../dyl"
> > ? }
> > }
> > 
> > Lets take for example the dependency "boo". A package "A" may
> > depend on
> > version "2.0.1" whereas another package "B" may depend on version
> > "2.3.x".
> Gaah, this is horrible.
> 
> > 
> > In this case npm installs boo at 2.0.1 in the subdirectory
> > "node_modules"
> > of package "A" and boo at 2.3.4 (assume 2.3.4 is the most recent
> > version
> > for 2.3.x) in the subdirectory "node_modules" of package "B":
> > 
> > {prefix}/lib/node_modules?????A
> > ???? ????node_modules
> > ?? ? ? ? ??? boo at 2.0.1
> > ???? B
> > ? ? ???? node_modules
> > ? ? ? ? ???? boo at 2.3.4
> > 
> > As Buildroot does not support different versions for most of the
> > packages I think we should only use npm to install Node.js
> > packages.
> Well, we can support this by having separate packages, but if they
> really break "boo" at every release and we need to package ten
> different versions of it, then it's a mess indeed.
> 
> > 
> > 
> > > 
> > > ?- What solution you propose to properly integrate this with the
> > > ???download and legal infrastructure of Buildroot. Right now,
> > > having
> > > ???"npm install" directly download and install stuff means that
> > > the
> > > ???download and legal-info infrastructure of Buildroot is
> > > completely
> > > ???worked-around. Due to this, "make source" will not download
> > > all
> > > the
> > > ???source, "make legal-info" will not list all the licenses,
> > > caching
> > > in
> > > ???BR2_DL_DIR doesn't work, BR2_PRIMARY_SITE doesn't work, etc.
> > I am not sure for now howto integrate this into the Buildroot
> > infrastructure properly. I have never thought about this, but it
> > will
> > need some work to be done, I guess.
> If you don't have Buildroot packages, it will be nearly impossible I
> believe.
> 
> > 
> > I have never had a look at?scancpan and I am not familiar with Perl
> > packages, but looking at some META.json files, I guess it could be
> > done
> > similiar.
> We have a similar script being worked on for Python, if you're
> familiar
> with Python. See for example http://patchwork.ozlabs.org/patch/501204
> /.
> 

Unfortunatly, scanpypi does not work with latest Buildroot. But I
tested scancpan and yes, I would say that we need something like this
for Node.js and npm. However, the problem with dependencies of
different versions is still there. For example Code-TidyAll depends on
Moo whatever version. scanspan fetches latest Moo version 2.* and
creates a fine buildroot package. The perl package Tropo however
depends on Moo 1.*. Installing this package with scanspac afterwards
does not change Moo, which is correct I think. However, building Tropo
will use the package Moo 2.*, which might fail (I've not tested).

Best regards
J?rg Krause

[Buildroot] [PATCH v3 1/1] jsen: new package

[Thomas Petazzoni]

Hello,

On Mon, 28 Mar 2016 16:01:09 +0200, J?rg Krause wrote:

> Unfortunatly, scanpypi does not work with latest Buildroot.

Ah. It would be great if some of our Python contributors could take
scanpipy, finish it and send it for merging.

> But I
> tested scancpan and yes, I would say that we need something like this
> for Node.js and npm. However, the problem with dependencies of
> different versions is still there. For example Code-TidyAll depends on
> Moo whatever version. scanspan fetches latest Moo version 2.* and
> creates a fine buildroot package. The perl package Tropo however
> depends on Moo 1.*. Installing this package with scanspac afterwards
> does not change Moo, which is correct I think. However, building Tropo
> will use the package Moo 2.*, which might fail (I've not tested).

This version-dependency thing is indeed a problem. For the specific
case you point out, the solution would be to have separate moo1 and
moo2 packages, very much like we do for python/python3, qt/qt5, etc.

However, this is only realistic if there are only a few "major"
versions for a few packages. If they break the API at every minor
release, then it's clearly not doable.

I personally don't really care about npm/node.js. Maybe we should just
add a big fat legal warning in our legal information when NPM has been
used to install additional packages, to explicitly say that those
additions are not listed in the legal info output. This would at least
warn the user.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v3 1/1] jsen: new package

[Matthew Weber]

Thomas,

On Mon, Mar 28, 2016 at 9:07 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Hello,
>
> On Mon, 28 Mar 2016 16:01:09 +0200, J?rg Krause wrote:
>
> > Unfortunatly, scanpypi does not work with latest Buildroot.
>
> Ah. It would be great if some of our Python contributors could take
> scanpipy, finish it and send it for merging.
>
> > But I
> > tested scancpan and yes, I would say that we need something like this
> > for Node.js and npm. However, the problem with dependencies of
> > different versions is still there. For example Code-TidyAll depends on
> > Moo whatever version. scanspan fetches latest Moo version 2.* and
> > creates a fine buildroot package. The perl package Tropo however
> > depends on Moo 1.*. Installing this package with scanspac afterwards
> > does not change Moo, which is correct I think. However, building Tropo
> > will use the package Moo 2.*, which might fail (I've not tested).
>
> This version-dependency thing is indeed a problem. For the specific
> case you point out, the solution would be to have separate moo1 and
> moo2 packages, very much like we do for python/python3, qt/qt5, etc.
>
> However, this is only realistic if there are only a few "major"
> versions for a few packages. If they break the API at every minor
> release, then it's clearly not doable.
>
> I personally don't really care about npm/node.js. Maybe we should just
> add a big fat legal warning in our legal information when NPM has been
> used to install additional packages, to explicitly say that those
> additions are not listed in the legal info output. This would at least
> warn the user.


Please reject this patch as we are not using it in the context of
NodeJS but instead with HTML5 and JavaScript served up by a standard
http server.  We're ok with just maintaining it internally at this
point.

Thanks!

-- 
Matthew L Weber / Pr Software Engineer
Airborne Information Systems / Security Systems and Software / Secure Platforms
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
www.rockwellcollins.com

Note: Any Export License Required Information and License Restricted
Third Party Intellectual Property (TPIP) content must be encrypted and
sent to matthew.weber at corp.rockwellcollins.com.