add spec file

[antedebaas]

This is an spec file for creating an rpm package.
i've used it to create a rpm file so i dont need cargo and rust on my production environments.
example file can be found here: https://repository.epicgreen.nl/

[flo-at]

Would it be a good idea to use GitHub CI to build a binary RPM package from this (at least for AMD64)? I'm thinking about adding the Arch Linux PGKBUILD, too. Would probably make it even easier to install and run MinMon. I'm busy this week but I'll review it asap.

[antedebaas]

yes, thats a great idea

[antedebaas]

wanted to figure out how it could be done.
ive added the pipeline to the PR

[flo-at]

Sorry for the late reponse, I've been quite busy lately.
The Arch Linux PKGBUILD can be found here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=minmon

What bugs me is the fact that the release version and in case of the PKGBUILD also a checksum of the source archive will be part of the repository if we do it the way it is done now. Also, the resulting binary packages will not be very portable as they are built with a specific version of Ubuntu/Arch at the time the CI runs. There's a good chance that they brake as soon as these distros update MinMon's dependencies.

I'm not sure yet how to solve these issues. Maybe by just adding the spec/PKGBUILD files and skip the CI part. The spec files could be template/.in files with placeholders that are filled in by the CI. It's just one command to build the respective package for the user. What do you think?

[flo-at]

I think the problem to solve here is similar to what Arch does with the AUR. For rpms there are similar services:

• Fedora COPR
• OpenSUSE Build Service

And a few more, but these two seem to be the most popular ones. Maybe that's the right direction to go.
The OpenSUSE Build Service can build for a variety of distros, that's quite nice.

[antedebaas]

I have limited experience outside of the RH ecosystem myself but a copr repository would do the trick yes.
You might want to have it in the main repo or in EPEL (https://docs.fedoraproject.org/en-US/epel/) eventually tho (dont know how that is for SuSE)

you would still need to build a src.rpm (rpmbuild -bs specfilename.spec) for that but you can do that on a pipeline and possibly submit to copr directly. But im not sure about that last past.

[musselmandev]

I would also like a rpm build, is there anything I can do to help get this on rocky?

[cap-cat]

I'd also like an RPM, but maybe an APT too ;-)

For simple packages (which this likely is), I'd recommend FPM. It needs a fairly long command line, but it's essentially just 'zip' but for packages. It feels likely that for a given architecture you could make an RPM and an APT easily from the same files, it's just two command lines, one asking for an RPM the other for deb.

Update:
I've had a bit of a play, and here's a working Github Actions that will compile and package into an Apt and an RPM:

jobs:
  build:
    name: "Build RPM"
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout Code"
        uses: actions/checkout@v4
      - name: Install Cargo
        run: sudo apt update && sudo apt install -y cargo openssl gcc
      - name: Prepare Rust build for multi-system
        run: rustup component add rust-std-x86_64-unknown-linux-musl
      - name: Build minmon
        run: cargo install --features systemd --target x86_64-unknown-linux-musl --path .
      - name: "Ruby Environment"
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: "3.3.5"
      - name: "Prepare FPM"
        run: gem install fpm
      - name: Prepare package
        run: |
            mkdir -p pkg/etc pkg/usr/bin pkg/lib/systemd/system
            cp systemd.minmon.service pkg/lib/systemd/system/minmon.service
            cp /home/runner/.cargo/bin/minmon pkg/usr/bin/minmon
      - name: "Package RPM"
        run: fpm -s dir -t rpm -p minmon-1.0-${{ github.run_id }}.rpm -v 1.0 --iteration ${{ github.run_id }}  -n minmon -m devops -C pkg .
      - name: "Package Apt"
        run: fpm -s dir -t deb -p minmon-1.0-${{ github.run_id }}.deb -v 1.0 --iteration ${{ github.run_id }}  -n minmon -m devops -C pkg .

[wxlg1117]

seems not for centos 8 ?

[antedebaas]

seems not for centos 8 ?

Centos 8 has been EOL for quite some time now

[antedebaas]

I'd also like an RPM, but maybe an APT too ;-)

For simple packages (which this likely is), I'd recommend FPM. It needs a fairly long command line, but it's essentially just 'zip' but for packages. It feels likely that for a given architecture you could make an RPM and an APT easily from the same files, it's just two command lines, one asking for an RPM the other for deb.

Update: I've had a bit of a play, and here's a working Github Actions that will compile and package into an Apt and an RPM:

jobs:
  build:
    name: "Build RPM"
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout Code"
        uses: actions/checkout@v4
      - name: Install Cargo
        run: sudo apt update && sudo apt install -y cargo openssl gcc
      - name: Prepare Rust build for multi-system
        run: rustup component add rust-std-x86_64-unknown-linux-musl
      - name: Build minmon
        run: cargo install --features systemd --target x86_64-unknown-linux-musl --path .
      - name: "Ruby Environment"
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: "3.3.5"
      - name: "Prepare FPM"
        run: gem install fpm
      - name: Prepare package
        run: |
            mkdir -p pkg/etc pkg/usr/bin pkg/lib/systemd/system
            cp systemd.minmon.service pkg/lib/systemd/system/minmon.service
            cp /home/runner/.cargo/bin/minmon pkg/usr/bin/minmon
      - name: "Package RPM"
        run: fpm -s dir -t rpm -p minmon-1.0-${{ github.run_id }}.rpm -v 1.0 --iteration ${{ github.run_id }}  -n minmon -m devops -C pkg .
      - name: "Package Apt"
        run: fpm -s dir -t deb -p minmon-1.0-${{ github.run_id }}.deb -v 1.0 --iteration ${{ github.run_id }}  -n minmon -m devops -C pkg .

Personally I’d use the official tools on an redhat based system to build redhat based rpms tbh

[flo-at]

Looks good so far.
How about the other features that are not enabled in this case?
Maybe a minimal version, as you posted above, with very few or no runtime dependencies is the easiest thing to do for now. Handling the dependencies for multiple distros, package formats, and architectures would be too much to maintain.
FPM looks like a good way to do this.
Would you mind to update the PR accordingly? Seems like we don't need the spec file in this case but just the GitHub Action, right?