ros-infrastructure/bloom — pull request #228 by cottsay (2014-02-06 03:48:45+00:00)
Title: RPM and ROSRPM Generator for Bloom

From what I can tell, Bloom has always intended to support non-debian packaging systems.

I've taken the debian packaging code and re-worked it to produce RPM spec files. These files are placed in the `rpm` directory, similar to the `debian` directory used to build for Debian.

The produced branches can then be built into a source RPM (.src.rpm) using the RPM build tool Mock, and the scm plugin for it. This method of building from git is employed similarly by the Fedora build system. The only difference is that in the Fedora build system, URLs are given to the source, instead of including the source and RPM spec file in the same repository. However, as mentioned, mock's build-from-scm module can handle this structure all the same, which is much more similar to the structure of the debian branches produced by Bloom.

An example mock command could look like:
```
mock --buildsrpm --scm-enable --scm-option method=git --scm-option package=ros-hydro-catkin --scm-option git_get="git clone https://github.com/smd-ros-rpm-release/catkin-release.git ros-hydro-catkin" --scm-option spec="rpm/ros-hydro-catkin.spec" --scm-option branch=rpm/ros-hydro-catkin-0.5.81-0_heisenbug --scm-option write_tar=True
```

#### A few things to note
* This patch simply ADDS support for RPMs; none of the ROS or debian scripts are touched (see the diff)
* The generated RPMs support version-specific requirements, "replace" keywords as well as "conflicts" keywords from Bloom
* The RPMs are rpmlint (an RPM analysis tool) compliant, minus the missing docs warning (this could be a new feature in Bloom) and an occasional missing URL (this is the fault of the package).
* Bloom patching works just the same as it does on the debian side.
* RPMs extract debug symbols from binaries, so each package has a separate "debuginfo" package. If someone wants debug symbols for one of the packaged binaries, they only need to install the "debuginfo" package to do so. This reduced the packaged size of hydro-desktop-full by 67 MB to 152 MB (excluding dependencies).

#### Proof-of-Concept
To demonstrate the capabilities of this addition to Bloom, I've forked all of the release repositories for packages which fall under ros-hydro-desktop-full, run git-bloom-generate on them to create the rosrpm branches, and compiled them with mock on my local machine.

These proof-of-concept repositories and RPMs can be found at:
Forked release repos: https://github.com/smd-ros-rpm-release (83 total repos)
RPM Repository: http://csc.mcs.sdsmt.edu/rosrpm-poc/fedora/linux/20/ (x86_64 only)

To try it out on a Fedora 20 x86_64 system, run:
```
sudo yum install http://csc.mcs.sdsmt.edu/rosrpm-poc/fedora/linux/20/x86_64/rosrpm-poc-release-20-0.1.fc20.noarch.rpm
sudo yum install ros-hydro-desktop-full
```

#### Some "quirks" worth mentioning
* The current versions of the underlay packages (catkin_pkg, rosdep, rosdistro, rospkg) that are bundled in Fedora are out of date. Updated versions are available in the rosrpm-poc repository above.
* The gazebo package for Fedora is currently under revision for addition to the main repositories. A modified version is available in the rosrpm-poc repository as well.
* Just like with the debian, ros-hydro-catkin needed to be patched. The same procedure was employed.

#### Moving forward
So much of the packaging process was the same between debian and RPM. I think some abstraction should happen; some kind of generic packager class which both systems employ and tweak for their specific needs. This would also help keep the RPM code from falling out of support in Bloom.

ROS on Fedora has come a long way. When I started using ROS on Feodra in Electric, it was completely unreasonable to try to get all of desktop-full compiling. Through the last releases of ROS and Fedora, however, *many* have strived to stabilize ROS on Fedora, and now there are very few problems running all of ros-hydro-desktop-full on Fedora 20 (if any). The stabilization of ROS as a whole has been a big part of that, as have other "bleeding edge" distros such as Arch.

Thanks for your consideration,

--scott