Add Static Linux Builds to CD

[RoboticMind]

Feature Request

Describe the Feature Request
The current CD deployment only covers Windows and MacOS builds. Adding a static Linux build would help make sure everyone has a build ready even if each distribution's build isn't ready yet. This may be especially important if a new release needs to be made for security reasons in the future. Github Action's cache system could be used to cache the depends builds and avoid making the builds take a long time.

Describe Alternatives
If Flatpack or any other more universal Linux packaging system is used, that would give the same benefit. It might just take more work to make that happen.

There also could be a build for each distribution, but this seems like it would be more work to maintain automated scripts for.

[caraka]

I built a gridcoin snap for over 6 months and couldn't find anyone to even test it on testnet. This was a while ago, and familiarity with snaps was much lower. I'm happy to revive the effort if people think it would get used. I always thought of it as a way to support less common distros. I was building 4.0.0 + for testnet. Guess that was a while ago!

[jamescowens]

I would rather do depends style static builds than snap builds.

[jamescowens]

Until we get this automated, I am adding static Linux x86_64 builds to the release assets. I am providing both bdb48 and bdb53 versions.

[hunleyd]

Until we get this automated, I am adding static Linux x86_64 builds to the release assets. I am providing both bdb48 and bdb53 versions.

did these make it into the 5.4.0.0 release @jamescowens ?

[jamescowens]

I haven't built them yet for the release.

[APCBoston]

@caraka @div72 I'm interested in taking this one on. Jim mentioned in the discord that I should check in with the two of you.

[div72]

@APCBoston @jamescowens Copying the job with depends should be enough in this case, but we do get this for free with #2689.

[APCBoston]

I was thinking of not just caching the build but automating the creation of .deb and .rpm packages including for ARM; my understanding is that all of that is currently done manually with each release. I don't expect it to be a huge lift and that plus something "universal" like a flatpak, appimage, or heaven forbid, a snap, would increase accessibility particularly for less-technical Linux users (yes they exist), decrease the delay from the tagging of a new release to the availability of packages for that release, and take the load off the individuals who are currently doing that packaging manually.

As far as comparing this work to #2689 , copying Jim's comment from the Discord:

I like the idea [of automating deb and rpm builds]. It probably means I will NOT adopt #2689, because I don't think we necessarily need to build ALL of that for every PR merge.

[div72]

Alright, I'd recommend starting with adding targets for deb/rpm files in Makefile.am. We can add it to the CD to get them automatically builded then.

[jamescowens]

My opinion is that an appimage build is effectively equivalent to a static build in that it has all of the dependencies in the self-unpacking archive. The depends style builds for Linux are flawed and do NOT produce truly static builds. They have remaining dependencies that make their portability across distributions limited. I am in favor of doing appimage for the fallback "generic" linux case rather than the depends style static build for Linux.

[jamescowens]

@caraka You need to weigh in here.

[APCBoston]

Alright, I'd recommend starting with adding targets for deb/rpm files in Makefile.am. We can add it to the CD to get them automatically builded then.

Not sure why it would be a Makefile target? rpm and deb are just structured ways of packaging what something like make install would do into a sparkling .tar.gz; maybe just because I'm more familiar with Github Actions than autotools but my inclination was just to add GHA jobs to pack them upon release.

[div72]

@APCBoston

Not sure why it would be a Makefile target?

• We don't rely on a specific CI, so you'd have to add it to the shell scripts instead of adding them as a GHA workflows.
• This can be useful to other people, so it'd be better if it was in someplace more accessible (like the main Makefile) rather than buried inside CI/CD scripts.
• Constructing files from files is what make is best at.
• The Windows(MSI) and MacOS Installers are also in the Makefile.am so it makes more sense to group it all up.

[div72]

My opinion is that an appimage build is effectively equivalent to a static build in that it has all of the dependencies in the self-unpacking archive. The depends style builds for Linux are flawed and do NOT produce truly static builds. They have remaining dependencies that make their portability across distributions limited. I am in favor of doing appimage for the fallback "generic" linux case rather than the depends style static build for Linux.

@jamescowens I hadn't checked before, the fact that depends style builds link to anything other than the libc is a bug that we should fix imo.

AFAIK AppImages are just inferior versions of static binaries. They don't get the performance benefits of inlining nor the size benefits of dead code elimination and they have to have a layer of indirection before they can be run.

[APCBoston]

* We don't rely on a specific CI, so you'd have to add it to the shell scripts instead of adding them as a GHA workflows.

I have no quibble with any of your other points, but this one has me scratching my head. The repo is in Github. Github provides GHA workflows as an available tool, and this project uses them for builds already... so in what sense do we "not rely on a specific CI" when we are in fact using GHA, and what would make a GHA workflow problematic?

[caraka]

@caraka @div72 I'm interested in taking this one on. Jim mentioned in the discord that I should check in with the two of you.

Definitely worth taking on. I built some appimages some years ago now, and they proved to be very unreliable at the time. AppImages have come a long way since then (as have we) and I am sure that w they would play nice now.