The ROS buildfarm currently supports building deb packages for the Ubuntu and Debian Linux distributions. Over the past year or so, I’ve been making steady progress on support for building RPM packages, which is the default package format for Linux distributions such as RHEL, CentOS, and Fedora. That work is now coming to a close, and the new functionality will soon be available to any ROS buildfarm configured to enable it.
For the most part, this change will have very little effect on existing deployments of ros_buildfarm, and no new jobs will be created unless the buildfarm configuration is updated to enable RPM packaging. When enabled, RPM-specific jobs are created in much the same way the existing debian jobs are created, and nearly all ros_buildfarm concepts like status pages, trigger jobs, sync jobs, and import jobs, exist and are supported for RPM packages.
For those not interested in enabling RPM support on their deployments, the only change you should be aware of is a deployment change related to the GPG keys. The RPM repository management solution being used runs inside Docker containers, and this required us to rethink our repository metadata signing approach. A new user account and group called gpg-vault will be created to house the GPG private keys, and a persistent GPG agent process will be run as that user on system startup. Membership in the new gpg-vault group and a little bit of configuration enables a user to perform signing operations using the running GPG agent while restricting direct access to the private keys to only the gpg-vault user account. We’re hoping to move the debian package metadata signing to use the gpg-vault as well, but we’re going to see how things go with the RPM signing first. For now, the new gpg-vault will be configured and started on all ‘repo’ deployments, but will only be used by RPM repositories (if any RPM repositories are configured).
tl;dr - you might see some new gpg-vault stuff getting deployed, but it won’t affect deb builds.
Timeline
Changes to ros-infrastructure/ros_buildfarm are already merged, and the next release will contain preliminary RPM support.
Changes to ros-infrastructure/buildfarm_deployment will be merged about 2 weeks from now, currently targeting 8/10/2020. At that time, the gpg-vault user/group/service will be created on deployment of the repo role.
Questions about RPM support
What RPM distributions are supported?
The current implementation was only tested on CentOS and Fedora, and there is currently no plan to expand to any other distributions. Linux distributions derived from that family, such as Amazon Linux or Scientific Linux will probably work out of the box, and might even be able to share the RHEL/CentOS binary packages without building them separately.
Other RPM-based distributions like openSUSE or Mandrake Linux would need Bloom changes to generate their style of RPM spec files, but as long as there are Docker images available and the package can be built with RPM mock, there should be a relatively small amount of work to enable builds.
What RPM distributions will be targeted on build.ros.org or build.ros2.org?
To start off, we won’t be enabling RPM builds on build.ros.org or build.ros2.org in the same way we build debs right now. We might create some RPM jobs to further test and mature RPM packaging support, but the packages won’t be made available and package maintainers won’t get notifications. If/when we think we’re ready to enable production RPM packaging on build.ros.org and/or build.ros2.org, we’ll let you know.
Why not use COPR/OBS/etc to build ROS RPMs?
There are several other release pipelines which are capable of building RPM packages, but none of them offer the same level of integration with the existing ROS packaging and release process that maintainers are familiar with. I, and others, have managed to package hundreds of ROS packages into RPMs in the past using other release pipelines and various levels of manual packaging and scripting, but I don’t believe that approach is sustainable. On the other hand, it would be unreasonable to expect ROS package maintainers to release their packages into an RPM-specific pipeline themselves, especially if they’re not interested in consuming packages for that platform. I’ve concluded that making the experience as uniform and integrated as possible is the path of least resistance to sustainable RPM packaging for ROS, and integrating into the existing pipeline accomplishes that. Keep in mind, however, that while this is a major milestone, it is only the first step towards general availability of ROS RPMs.
Which ROS packages can be built into RPMs using this feature?
All ROS packages that have rosdep rules for RPM package names for all of their dependencies can generate RPM spec files using Bloom, however there are system packages that may differ from the Ubuntu system packages in ways that prevent the package from building successfully.
Does [INSERT BUILDFARM FEATURE] work right for RPMs?
Most of the typical ros_buildfarm features are supported for RPM packages. Feel free to take a look at the tracking ticket for a feature-level overview: https://github.com/ros-infrastructure/ros_buildfarm/issues/736
If you have any additional questions, please feel free to share them!