Hello, in the pkg-security team we have greenbone-security-assistant (gsa) which is a web interface for gvm (former openvas-manager), the version currently in Debian no longer works with the latest gvm so we have to update it to the latest upstream release... but the latest upstream release has significant changes, in particular it now relies on yarn or npm from the node ecosystem to download all the node modules that it needs (and there are many of them, and there's no way that we will package them individually).
The Debian policy forbids download during the build so we can't run the upstream build system as is. As I see it we have three options: 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. 2/ disable this download during the package build, move the package to contrib, and add some code in the postinst to download the required node modules at package installation time (possibly with a debconf confirmation prompt and a command that the user can rerun afterwards to do it later). 3/ get rid of greenbone-security-assistant in debian and keep it in kali only (all the work I do in pkg-security is part of my Kali work), that would be a regression from the current situation and is something that I'd like to avoid. We try to contribute back to Debian, but there's only so much busy-work that I'm willing to do to achieve this goal. What option shall we pick? Shouldn't we relax some requirements to avoid having to resort to that kind of hackery? Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
