[Request] Make debian/rpm buildscripts open source

[theofficialgman]

Since this issue remains unfixed and is a hot toppic of discussion (nodejs/node#43246) there needs to be transparency and open instructions for the creation of debian and rpm packages as distributed through this repo.

repository setup is not needed but the scripts utilized to check for nodejs updates as well as create the deb/rpm packages should be made open source so that other packagers who wish to create alternative repositories for this distributions repository which matches the packaging here exactly can be made.

[theofficialgman]

cc: @igsu since you are the listed maintainer for the debian packages. the nodesource repos do not have source files for the debs so they can not be reproduced

[riosje]

CC @edsadr

[riosje]

@theofficialgman
I understand this requirement is because of the need to have Node18 bin and installers for ubuntu 18 and/or amazon linux 2.
we're going to make some tests building Node18 with glibc 2.26, with this we can bring support to ubuntu and amazon linux 2.
let you know any news on this.

[theofficialgman]

@theofficialgman I understand this requirement is because of the need to have Node18 bin and installers for ubuntu 18 and/or amazon linux 2. we're going to make some tests building Node18 with glibc 2.26, with this we can bring support to ubuntu and amazon linux 2. let you know any news on this.

this is a reason for my personal desire for having the scripts open source, yes, but its not the only reason for doing so. right now the debs/rpms are unreproduceable by 3rd parties (like myself). like I have already shown here #1492 the buildscripts need modification to prevent installation on unsupported configurations (incorrect control file and to this day still being posted in the 16.04/18.04/18.10/19.04/19.10 apt repo). I would fix it myself but since they are closed source I cannot do so.

[eugene1g]

@theofficialgman We still need NodeSource buildscripts to be open sourced, but FWIW I checked ~20 RPM packages of Node 18 for for EL7-EL9, FC34-FC37, and in every case the bin/node binary was exactly the same as downloadable directly from Node.js. In other words, you can wget official tarballs and get the same executable.

[theofficialgman]

I don't care that the executables are the same.
having the tarfiles is not the same as a generated deb or rpm.
how is the debian control file made? how are the tarfiles converted into formatting for debs and rpms? what about changelogs, how are those generated and placed?

I could go on, all of these things are being done by the buildscripts that are closed source which prevent the creation of compatible debs/rpms. In order to properly create these packages so as to not conflict and properly setup we need the buildscripts.

[theofficialgman]

on top of that. since the buildscripts are fundamentally broken and nobody here seems to care to fix them (coming up on a 1 year anniversary of broken scripts, YAY) they definitly need to be made open source. I would gladly submit a PR to fix: #1492 #1400 but I can't do that if the buildscripts are closed source

[eugene1g]

@theofficialgman I agree. I evaluated what was the value-add from using NodeSource distributions, and found out that it was negligible versus how many pain points we're experiencing. So we moved our infra to use "plain" tarballs from Node, as that path gives us most flexibility about what/when we deploy, while (and this was the surprising part) keeping the same level of assurance that the release would work for our OS.

I'm not saying you should use tarballs too. I'm saying I was surprised to discover that the binaries were exactly the same, and that was all I needed to retire NodeSource from our pipeline - fewer moving pieces, less lock-in on opaque 3rd party files, and less trust required in the supply chain.

[cobalt2727]

@theofficialgman We still need NodeSource buildscripts to be open sourced, but FWIW I checked ~20 RPM packages of Node 18 for for EL7-EL9, FC34-FC37, and in every case the bin/node binary was exactly the same as downloadable directly from Node.js. In other words, you can wget official tarballs and get the same executable.

This is exactly the problem, though. Having the executable be the same everywhere breaks older operating systems. That's what gman wants fixed here by open-sourcing the build scripts.

[theofficialgman]

while (and this was the surprising part) keeping the same level of assurance that the release would work for our OS.

no, that is just blatently wrong. that is what packaging as a proper rpm and deb solves. downloading the tarbar directly and using it provides NO level of assurance at all. debs and rpms have listed dependencies and versions associated with those dependencies that prevent installation on OSs where the binaries will not work (eg: Depends: libc6 (>= 2.17), libgcc1 (>= 1:4.2), libstdc++6 (>= 5.2), python3-minimal, ca-certificates ) . again, that is broken currently and has been for over a year #1492 but if it was implemented properly (like if the buildscripts were open source and fixed) then you could simply tell from the package what EXACT systems the binaries would work on.