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