-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPM builds #299
Comments
For building rpms i always liked copr. You get repository generation for free and it's arguably easier to set up.
|
I see that 1.0.0 has been tagged which is super exciting news! Congrats to the project! Any interest in this packaging issue? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Some other issue mention CentOS as the likely target (7 being the last & soon EOL).
Some issue(s) are about SLES.
It is important to note that Ceph Pacific RPM packages are only built for EL8; Quincy has EL8+EL9.
2.3.16 for EL8 and EL9.
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:
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.
The text was updated successfully, but these errors were encountered: