Resolving a conflict

Jun 15, 2018 15:06 · 273 words · 2 minute read

When you are hear 2 coworkers complaining about breaking each other’s changes to a package, you wonder what is going on. And this time it turns out they were complaining about a rubygem package. So yeah time to find a nice solution to this problem finally.

The conflict

rubygem-annotate and gd. Both provide a /usr/bin/annotate. In the case of our gem based packaging this is of course only a symlink handled by update-alternative. Though the code handling this is split over 2 places - the script that handles installing each gem and our template for the subpackages.

Resolving the conflict

The key to the solution is of course our gem2rpm.yml. The question was of course how to solve it. After some pondering I settled with a simple hash to map binary names around.

:binary_map:
  annotate: annotate-rb

Sounds simple enough no?

The next step was to patch the gem_package.erb. A simple helper function to check if the hash and hash key exist and then mapping the value around, calling it in the right places.

gem_install.sh was a bit more tricky. It did not use the gem2rpm.yml yet. But we already had code there to find the gem file. So it was easy to adapt it to also find our gem2rpm.yml for us. Sadly a lot of code between the script and the template look similar and you might wonder why we dont share it …. because we need gem_install.sh to well package gem2rpm itself :)

So now we have a nice way to resolve the conflicts and the 2 coworker can complain about other things. There is no shortage on things to complain about.