On Thu, Dec 17, 2020 at 2:19 pm, Raphael Hertzog <hertzog@debian.org> wrote:
Hello, On Thu, 17 Dec 2020, Pirate Praveen wrote:>1/ download all the node modules and add them to the source package, but >then it's just impossible to write a copyright file to document the source>package. That would be the best option though, the yarn.lock file >effectively locks a very specific version of each node module so>even though it's downloaded the net effect is very similar to "vendoring">as is done by other projects.This will only work for a subset of modules because most modules will not be just source (unlike golang), it will contain prebuilt files. Theoriginal source is usually ES6 or typescript usually and you need to build them using babel/rollup/typescript.I don't understand what you mean. Are you trying to say that this won't help much because we will have another DFSG-freeness problem in the sense that what we would embed is not the source and that DFSG requires us toprovide the sources?
yes. Most modules now ship files generated by tools like babel/rollup/webpack/typescript etc. So we will have to get their preferred source code from their source repos and build them in debian.
For example d3-color module ships files generated by rollup, which we rebuild in debian.
https://salsa.debian.org/js-team/node-d3-color/-/blob/master/debian/rules#L8You may still be able to vendor the original source of these modules and only build the final app with tools like webpack, but that would be different from what upstream does (upstream pulls all prebuilt modules from npmjs.com) and some modules may even have other custom build steps/tools.
add-node-component from pkg-js-tools makes it easy to vendor original source code.
So even if you can't vendor all modules easily in one shot, I think you can still manage a lot of modules that way and package only the smaller subset that you can't vendor.
We also have tools to build vendored code.For example, pirates is module vendored in node-babel using their preferred source and built in debian
https://salsa.debian.org/js-team/node-babel/-/blob/master/debian/gbp.conf https://salsa.debian.org/js-team/node-babel/-/blob/master/debian/nodejs/pirates/build Older modules were simpler and did not require any build steps. So it was easy to vendor these modules in node-gulp, https://salsa.debian.org/js-team/node-gulp/-/blob/master/debian/gbp.conf
I use this option for gitlab, but I want to eventually move it to mainonce I package all of them. Out of 1700+ node modules, I'm left with 270+ node modules pulled outside of main. I remove already packaged modules from package.json.I appreciate all the efforts that you are doing here but to me it seemslike a dead end. Much like the idea of adding another repository to accomodate the ever-growing list of go modules that nobody will ever want to use except as a build-dependency. To me it seems that we must adapt our rules, our expectations and ourtooling to cope with this paradigm shift where dependencies are downloadedat build time.
Well, its indeed a conflict of different values. It may indeed be a losing fight, but I prefer to still fight this as much as I can. Many developers want the distributions to be just base for containerized apps, but I don't like that vision. It is indeed easier for developers this way, but I don't necessarily think that is the best way for users.
I think reproducible builds and the guarantee that every package is built from source by debian and anyone can rebuild easily are still valuable goals from a security perspective.
I try to bring in more people to traditional packaging side and if we are able to get more people to realize the value in what we do, we can still manage. But it is no way an easy task.