On 14500 March 1977, Michael Prokop wrote:
>> > 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?
It neither helps Users nor Debian.
>> 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.
This is an ugly two sided sword.
On the one side we do hate embedded code copies. For good reasons.
hate JS with a passion, thats not a nice thing to have such a mess.
Now, until now, whenever those tons of little packages got a suggestion
to make sensible and useful bundles, it got yelled down to "impossible",
Which I can understand if it means doing it yourself.
Which doesn't seem to be the case here. So taking such an upstream
bundled package seems to be good.
So yay, go for it.
With a caveat or two:
- This is not a blanket for having embedded code copies all over the
So yes, this should Provide: all those submodules and make them
usable by whoever depends on it.
- This must be rebuildable in Debian. That is, the package should, in
its source, contain what upstreams source uses to build its final
files. Ie. whatever their build script downloads to bundle the
files together. Not just the final
"browserified"/"mangled"/"whateverthecurrentspeakis" version only.
And be able to redo that build process using them.
- Good luck in listing the copyrights. :)