Hi, On Thu, 17 Dec 2020, Jonas Smedegaard wrote: > > Out of curiosity, I have run your script on the package.json file of > > greenbone-security-assistant and this just confirms that it's not > > realistic to package everything separately: > > https://wiki.debian.org/Javascript/Nodejs/Tasks/gsa > > Nice. Doesn't look like an impossible task to me.
It looks like a huge amount of work that does not bring any value compared to the Kali package relying on the upstream build system without any tinkering. > In reality, most Nodejs modules declare too tight versioning for their [...] I know this, but I also know that such an analysis is very time-consuming and needs a good knowledge of the language and of the upstream package, which I don't have. > In your original post you seemingly already ruled out proper packaging > as a premise, and it seems you continue to use absolutes like > "everything" and "never". I find that discouraging - plase consider a > less negative tone. Sorry, I don't want to discourage you. But I'm also sure that I will never be able to justify spending days and weeks on packaging (and then maintaining) all those node modules for the benefit of pushing a single package to Debian when said package was updated in Kali in a matter of hours. By trying to shoehorn node/go modules into Debian packages we are creating busy work with almost no value. We must go back to what is the value added by Debian and find ways to continue to provide this value while accepting the changed paradigm that some applications/ecosystems have embraced. And for me selling points are: - ensurance that we use DFSG free code only => we can have tool to review licenses of what has been downloaded during build and embedded in the binary packages - ease of installation and reliability => we are doing bad now because many useful things are not packaged (due to the mismatch between our rules and those not-longer-so-new ecosystems) and when users have to manually install, the reliability goes down... - possibility to rebuild from source => we could have some sort of proxy that would store everything downloaded and let us rebuild an identical package without net access even if the remote resources disappear - security support => we need to be able to identify packages that are vulnerable because they have embedded a problematic version of a node/go module, again we need tools that analyze what got embedded in the binary package and make this easy to query BTW, that's the kind of infrastructure development that would advance the cause of Debian and that I would be glad to (start to) fund through https://salsa.debian.org/freexian-team/project-funding Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
signature.asc
Description: PGP signature
