Set up nFPM to build .deb and .rpm

[kradalby]

This commit simplifies the goreleaser configuration and then adds nfpm
support which allows us to build .deb and .rpm for each of the ARCH we
support.

The deb and rpm packages adds systemd services and users, creates
directories etc and should in general give the user a working
environment. We should be able to remove a lot of the complicated,
PEBCAK inducing documentation after this.

Issue and PRs related to poor docs that could be fixed by this:

• Improve docs #1221
• Documentation issues #1217

[kradalby]

For the record, I have tested the deb package for arm64 on Ubuntu, bit not RPM, would be helpful if someone can do that.

[juanfont]

Noice!

[jonathanspw]

Would you prefer to use more native packaging methods for building the RPMs to be consistent with packaging guidelines and policies used by Fedora/EPEL/RHEL?

I'm a Fedora/EPEL packager and happy to help with this if you're open to using a different build process than nFPM.

[kradalby]

@jonathanspw, Thanks for offering, it is really appreciated, I am not familiar with RPM (nor have I used RPM based distros), and I am concerned that it would be a bit of a cliff to both maintain multiple packaging methods and learn the details (while I have heard RPM is easier/better than .deb), might become tech debt for us quite quickly.

Happy to be convinced otherwise, is there any problems with the current packages that probably cant be addressed with nFPM?

[jonathanspw]

Here's just a few less-than-ideal things it's doing:

[jonathan@jon-office ~]$ rpmlint headscale_0.22.0-alpha2_linux_amd64.rpm
================================================ rpmlint session starts ================================================
rpmlint: 2.4.0
configuration:
    /usr/lib/python3.11/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-legacy-licenses.toml
    /etc/xdg/rpmlint/fedora-spdx-licenses.toml
    /etc/xdg/rpmlint/fedora.toml
    /etc/xdg/rpmlint/scoring.toml
    /etc/xdg/rpmlint/users-groups.toml
    /etc/xdg/rpmlint/warn-on-functions.toml
checks: 31, packages: 1

headscale.x86_64: W: systemd-unit-in-etc /etc/systemd/system/headscale.service
headscale.x86_64: W: summary-not-capitalized no description given
headscale.x86_64: W: non-conffile-in-etc /etc/systemd/system/headscale.service
headscale.x86_64: W: non-coherent-filename headscale_0.22.0-alpha2_linux_amd64.rpm headscale-0.22.0~alpha2-1.x86_64.rpm
headscale.x86_64: W: no-manual-page-for-binary headscale
headscale.x86_64: W: no-documentation
headscale.x86_64: E: no-changelogname-tag
headscale.x86_64: E: no-binary
headscale.x86_64: E: dir-or-file-in-var-run /var/run/headscale
headscale.x86_64: W: dangerous-command-in-%postun rm
headscale.x86_64: W: dangerous-command-in-%post chown
================= 1 packages and 0 specfiles checked; 3 errors, 8 warnings, 3 badness; has taken 0.1 s =================

In addition, my intent is to build and maintain a repository for headscale on RPM distros (Fedora/EL*) which people can install and then natively upgrade as I push upgrades, etc. If the RPMs from CI are built in the same manner then it would allow people to seamlessly upgrade to using the repository, or upgrade from a CI RPM prior to the repository getting an update, and all work seamlessly together.

It looks like we're going to be using headscale at AlmaLinux (I'm the infra lead over there) so I'll be able to help maintain this in CI indefinitely and it will be basically identical to the work I'll be doing in the repository anyway - ie mostly copy/paste.

I currently do this for another project, ImHex, so here's an example of what it could look like within GH CI (again I'll take care of PRing this if you're open to it): https://github.com/WerWolv/ImHex/blob/master/.github/workflows/build.yml#L469

and the actual RPM spec file: https://github.com/WerWolv/ImHex/blob/master/dist/rpm/imhex.spec

There are some extra complexities in each of these that are specific to ImHex that wouldn't be needed for headscale so it would be a bit simpler in practice here.

[kradalby]

In addition, my intent is to build and maintain a repository for headscale on RPM distros (Fedora/EL*) which people can install and then natively upgrade as I push upgrades, etc. If the RPMs from CI are built in the same manner then it would allow people to seamlessly upgrade to using the repository, or upgrade from a CI RPM prior to the repository getting an update, and all work seamlessly together.

It looks like we're going to be using headscale at AlmaLinux (I'm the infra lead over there) so I'll be able to help maintain this in CI indefinitely and it will be basically identical to the work I'll be doing in the repository anyway - ie mostly copy/paste.

I appreciate that, it sounds very good, I wonder if at this point it makes sense for us to publish RPM at all? Would it not be more beneficial to keep it in one place, which would be the main repo you provide?

I currently do this for another project, ImHex, so here's an example of what it could look like within GH CI (again I'll take care of PRing this if you're open to it): WerWolv/ImHex@master/.github/workflows/build.yml#L469

and the actual RPM spec file: WerWolv/ImHex@master/dist/rpm/imhex.spec

So based on this I have a couple of questions/concerns:

Why can we not beat nFPM into releasing RPMs that fulfils the requirement?
While I appreciate that someone else (you), will be maintaining this spec and pipelines, they do not seem particularly trivial to me, and the amount of sed calls and platform specific knowledge needed to operate them looks like it will be a problem for us if you or Alma decides to go in a different direction.

It will be a lot harder to remove RPMs than adding them.

I appreciate that nFPM is a "one tool to do them all, to mediocrity", but from our tech debt/maintenance perspective, those 90% might be good enough.

On the other hand, referring to the first part, if you are doing a proper RPM, then one alternative is to not publish it from our side and rather refer to the repos. In which case, we would be grateful for that contribution!

[jonathanspw]

I'm working on the basis for the repo/RPMs now. Once I get that done I'll let you review it, how it will work, and then we can discuss further :)

[kradalby]

Sounds good, I will do docs and releases for .deb in the first round then, and then we can add back .rpm when we figure this out!