Hi, Robert
On Sat, Feb 13, 2016 at 4:07 AM, Robert Schweikert
Yes, so this is going to be one problem with this approach, but this is not really to your doing. Most problems with node.js are caused by the basic design decisions about handling dependencies. Unfortunately we will probably find that many upstream projects do not care about license compatibility and will just mix and match components as they see fit. The problem for us as a project maybe that we cannot distribute such a bundle, but IANL. We'll see how this fairs in legal review if such a package is ever proposed for inclusion in TW or Leap.
Luckily the modules are not compiled into each other 99% of the times. They are isolated enough (lives in their own directory) in the bundle. So the real challenge I think is whether our license digger has powerful enough tools to check all those pieces of files...I can also help by bundling one in the toolkit itself of course.
node.js basically provides the approach that one has the same module in a number of versions in various places on the system (in each bundle). If one version has a security issue it is not easy to determine if a.) one has the module with the security issue installed; and if one has it b.) which bundle provides the faulty module. Therefore, one is completely dependent on the person/team that develops the bundle to provide an update to the "application" that includes a fixed module, or I should say a pointer to a module without the problem such that it is pulled properly.
Actually it's easy to find the faulty module with specific version :-) npkg will generate a "<name>.json" with the same format. https://build.opensuse.org/package/view_file/devel:languages:nodejs/gulp/gul... And I have figured out the download URL for such json files from OBS. so finding a hash key with a specific value is really basic topic in Ruby... I even drafted a statistics tool (/usr/bin/npkg-mgmt-json-statistics) that gets how popular a specific module is (by counting its appearance across .json files) Well to make upstream to update the faulty module is another story... Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org