Package the CLI application on RPM-based distributions

[gridhead]

This includes distributions like RHEL, Fedora, CentOS, Mageia, OpenSUSE etc.

I can assist with that but I'd need the build instructions first.

[gridhead]

There seems to be an already existing package for Fedora here. https://src.fedoraproject.org/rpms/exercism.

[iHiD]

If we had the script referenced in #973 that lives at https://exercism.io/get-exercism - what else would need to happen to make this work? Would you be building the Golang code per OS, or could you download it from the website etc?

[iHiD]

(I'm tagging @ErikSchierboom here to own this as I know nothing about it, @ekingery who understands how the CLI gets built, and @NobbZ/@kotp who seem to know how computers work)

[ekingery]

We use GoReleaser to create portable binaries and provide snap and homebrew packages. It stops short of distro-specific RPM packaging. For that, we would need to add a build step (and some docs / instructions, etc). Most people use FPM. The team behind GoReleaser created nfpm which I would prefer to use if possible for the simplicity and compatibility with automation / the current build process. This post points out that creating RPMs is straight forward, but the bigger challenge is getting the RPMs uploaded to the distro's repositories, which mirrors our experience.

The upshot is that creating RPM packages should be a fairly simple bolt-on to our current build and release process. Getting them uploaded to the corresponding repositories is a more involved process and probably the bulk of the work (and ongoing responsibility unless it can be automated like the current snap and homebrew process).

[iHiD]

Thanks Eric :)

But, even if its hard (delayed) to get into the distro repos, we could at least provide the RPM packages for people to install anyway. Which seems like a good thing?

[ekingery]

Thanks Eric :)

But, even if its hard (delayed) to get into the distro repos, we could at least provide the RPM packages for people to install anyway. Which seems like a good thing?

Sure, although in my opinion it's added complexity for marginal gain until we get the RPM into a PPA. Right now if you are on linux and don't want to use snap, you can download the .tar.gz file, unzip it and you have your binary. That said I do understand that an RPM has advantages over the tarball.

In terms of release administration, GoReleaser currently uploads all of the files. In addition to building the RPM, adding it to the Github release may require some GoReleaser scripting / config or require a manual upload of the RPM for each release. I recommend waiting until we have the time / resources to do it properly and get the RPMs all the way into a PPA. However, I defer to you and @NobbZ / @kotp on what's best for the project - I'm happy to review any corresponding PR.

@t0xic0der, here is the existing release documentation / build process: https://github.com/exercism/cli/blob/main/RELEASE.md

[gridhead]

We use GoReleaser to create portable binaries and provide snap and homebrew packages. It stops short of distro-specific RPM packaging. For that, we would need to add a build step (and some docs / instructions, etc). Most people use FPM. The team behind GoReleaser created nfpm which I would prefer to use if possible for the simplicity and compatibility with automation / the current build process. This post points out that creating RPMs is straight forward, but the bigger challenge is getting the RPMs uploaded to the distro's repositories, which mirrors our experience.

I am afraid it is not quite so. Once someone has an RPM specfile ready, they can either make their way to COPR and have it packaged for a multitude of distributions in a way, PPAs do in DEB-based distributions. Following is a snapshot of me packaging one of my own applications and running automated builds to check if they build just fine or not.

The upshot is that creating RPM packages should be a fairly simple bolt-on to our current build and release process. Getting them uploaded to the corresponding repositories is a more involved process and probably the bulk of the work (and ongoing responsibility unless it can be automated like the current snap and homebrew process).

The current maintainer of the Exercism RPM package, which you can find here, makes it available only on Fedora versions 32 onwards and on Rawhide. I would have to take a look at their RPM specfile first, to see if I can make them available on RHEL7 (EOL imminent), RHEL8, CentOS 7 (EOL imminent), CentOS 8 Stream, Mageia, OpenSUSE Leap, OpenSUSE Tumbleweed etc. via a COPR.

Thanks Eric :)

But, even if its hard (delayed) to get into the distro repos, we could at least provide the RPM packages for people to install anyway. Which seems like a good thing?

There are some circumstances where that may fail to work, especially when there are dependencies that are not packaged natively in the distribution being targetted, but we can give it a try. :)

Sure, although in my opinion it's added complexity for marginal gain until we get the RPM into a PPA. Right now if you are on linux and don't want to use snap, you can download the .tar.gz file, unzip it and you have your binary. That said I do understand that an RPM has advantages over the tarball.

In terms of release administration, GoReleaser currently uploads all of the files. In addition to building the RPM, adding it to the Github release may require some GoReleaser scripting / config or require a manual upload of the RPM for each release. I recommend waiting until we have the time / resources to do it properly and get the RPMs all the way into a PPA. However, I defer to you and @NobbZ / @kotp on what's best for the project - I'm happy to review any corresponding PR.

@t0xic0der, here is the existing release documentation / build process: https://github.com/exercism/cli/blob/main/RELEASE.md

You must be referring to COPR when you say PPA (for PPAs are a thing in DEB-based distributions but not in RPM-based ones). I should be able to refer the existing RPM specfile built by the existing maintainer and have it packaged for other distributions as well and then I can share the specfile as a PR, and according to that changes can be introduced to the automated build process.

[ekingery]

You must be referring to COPR when you say PPA (for PPAs are a thing in DEB-based distributions but not in RPM-based ones). I should be able to refer the existing RPM specfile built by the existing maintainer and have it packaged for other distributions as well and then I can share the specfile as a PR, and according to that changes can be introduced to the automated build process.

Indeed - apologies for mixing up distro flavors - I've been in DEB-land for so long that I am out of touch with the equivalent. That's great if you can re-use the RPM specfile. I defer to @iHiD and co. here, but for me the most important factor is having a reasonable and canonical process by which we (someone on the exercism team) can control the packaging and distribution of the "official" RPMs. If that is in place, and it doesn't add a significant amount of work to ship a release, then I would be grateful for the assistance in distributing the CLI client to as many distros as is feasible. Thanks for the offer to help Akashdeep!

[kotp]

Also, we note that we are attempting to deprecate the snap distibuted package, as it is the most reported problem for users starting out. Admittedly I have not taken the time to understand the snap package management, and not highly motivated to when installing manually is a matter of downloading the executable that is built for the architecture already and placing it into the $PATH somewhere, (often for Debian based systems in ~/bin).