Re: How should we handle greenbone-security-assistant?
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?
> 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.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Reply to: