On Thu, Dec 17, 2020 at 2:19 pm, Raphael Hertzog <hert...@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.
The
original 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
to
provide 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#L8
You 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
main
once 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
seems
like 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 our
tooling to cope with this paradigm shift where dependencies are
downloaded
at 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.
