RPM builds

[bluikko]

Is your feature request related to a problem? Please describe. I understand that this project is not at release stage but I propose to discuss RPM packaging as that point draws closer.
And providing RPMs even for the development versions could help to reach more users to help in testing. In the absence of testing in CI, having automatic builds, possibly for various targets, also provides valuable feedback for development.

There are many variables to consider when releasing RPM packages. I have not noticed discussion on what would be the target environment(s) so I hope this issue could provide information to interested users and to gather feedback and opinions on the issue.

• Distribution: most likely EL8 and EL9 could be targeted?
  Some other issue mention CentOS as the likely target (7 being the last & soon EOL).
  Some issue(s) are about SLES.
• Ceph release: Pacific / Quincy?
  It is important to note that Ceph Pacific RPM packages are only built for EL8; Quincy has EL8+EL9.
• Dovecot version: would likely follow the distribution Dovecot version?
  2.3.16 for EL8 and EL9.
• Architecture: x86_64 seems like the obvious architecture.
  32-bit builds seem not important to me, at least initially.

Describe the solution you'd like I propose that the RPM package is built using GitHub Action. It is an easy solution and then releasing RPM packages will not take valuable developer time.

Proposed targets:

• x86_64, EL8, Ceph Pacific (and Quincy?), Dovecot 2.3.16.
• x86_64, EL9, Ceph Quincy, Dovecot 2.3.16.

These 2 targets seems to me to be most useful: one conservative choice & one bleeding edge.

Describe alternatives you've considered There are probably alternative RPM build servers but I am familiar with GitHub Actions and could probably volunteer to attempt for that specifically.

The other option is to not build RPM packages for releases which would be very inconvenient for majority of the users.
Using a CI/CD pipeline would be of tremendous value for those users who have limited resources.

Additional context Another venue for discussing RPM packaging could be GitHub discussions but that feature is not enabled for this repository.

[ibotty]

For building rpms i always liked copr. You get repository generation for free and it's arguably easier to set up.

[bluikko]

I see that 1.0.0 has been tagged which is super exciting news! Congrats to the project!

Any interest in this packaging issue?
I think I will take a look at making a pipeline for the RPM packaging when I can.