v0.1.1 Packages Broken -> v0.1.2 Release

Owned by Michael Stay (Unlicensed)
Mar 15, 2018
2 min read
The packages for the node were not being built correctly, meaning that users who downloaded the Debian package could not install the software and then run the node without modifying their environment (e.g., by adding /usr/share/rchain-node/usr/bin to their PATH).
It looks to me like they didn't get tested correctly before Jeremy approved the pull request and no one reviewed the packages for correctness before the release went out. Henry and I fixed this, but we ended up changing several packaging details.
  1. The package is renamed from "rchain-node" to "rnode" because Scala symbols can't have "-" in them. This probably wasn't strictly necessary, but "rnode" won the community poll anyway.
  2. The binary installed is renamed from "node" to "rnode" and can be reached at the usual location: /usr/bin/rnode.
  3. The JAR files that get distributed are now correctly "vendored," as Henry calls it, so you see them all in the /usr/share/rnode/lib directory. The Debian requirement for Java JAR files is to install them into a private directory in /usr/share/<package>, which is now done correctly.
  4. The Debian package name is now the same in the filename and the control file in the package. (It wasn't before, meaning you had to install with dpkg -i rchain-node_0.1.1_all.deb but to uninstall you had to run dpkg --remove node which was totally weird).
We fixed all of this by modifying the built.sbt file. Henry's pull request also deleted all the 0MQ code that isn't used. So, there's a lot of LOC in the PR.
We then cherry-picked this to master, rebuilt the packages, and published a new release under the tag v0.1.2. Everyone should refer to the new release as "0.1.2" and not "0.1.1" in our communications. Please make sure that any public communications get updated to reflect this. It's already in my medium post that was submitted this evening to the RChain Pub.
TODOs:
1. Testing should check every package for /usr/bin/<binary> for all critical binaries.
2. Testing should check that JAR depencies are installed into /usr/share/<package>/lib and carry the correct version information with them.
3. Testing should install the package, run a smoke test, and uninstall it.
4. Testing should extract deb files and check that the filename matches the package name in the control file.
These tests would have caught and documented the specific packaging failure, so if implemented, they ought to prevent this from happening again. I suggest implementing these in the CI environment for now, but the packaging commands are slow, and this may result in increased latency for some pull requests. We can discuss whether or not there should be more extensive checks during the "merge to master" pull request than for others, but I have no idea how to implement that in GitHub. I think it would be easy in GitLab CI. Alas.
Regards,

Nash E. Foster
Founder
Pyrofex Corporation