currently when we package Ruby gems, they all end up as rubugem-foo in foreman-packaging. This makes it very hard to see whether a specific gem has to be built for the system ruby, or for our SCL (or both). The only way to know where a package belongs is to look at tito.props and read all the tags and whitelists there.
I would like to propose to be more explicit here, and call the packages that go inside the SCL tfm-rubygem-foo in the packaging repo (they are called like this inside Koji anyways). However this also means that we end up with duplicated data in the case where a gem has to be built for both Rubies.
FWIW, that’s how we’ve been handling downstream packaging for some time now, and it’s really convenient
Pros
easy mapping from Koji to packaging folder
no guessing which ruby a gem belongs so
easier automation of building because of the above
I’m not against it per se, but until we have more automated tools to do version bumps I think the additional overhead for packages that are built in both is too much and too error prone since we have no automated reviewing tools to notice we need to bump both packages.
Compare it to the change to drop the use of tags. Previously we didn’t need to write changelogs at the cost of a bit more (scripted) work and a more verbose git log. Now we need more manual work. Cherry picks are more work because we changed the workflow. For now I still consider dropping tags a net loss in productivity and I’m afraid this change will end up in the same way.
If the desire is to know where a package is built, why not start with a package2tags script instead until we fix the other issues.
In that case, I think it’d be OK especially since these are not revved very often. Not to mention, our SCL ruby is progressing further than the installer Ruby and we may need to rev them separately.
#!/usr/bin/env python3
from collections import defaultdict
from configparser import ConfigParser
parser = ConfigParser()
with open('tito.props') as fp:
parser.readfp(fp)
packages = defaultdict(list)
for tag, section in parser.items():
for package in section.get('whitelist', '').split():
packages[package].append(tag)
for package, tags in sorted(packages.items()):
if len(tags) > 1:
print('{}: {}'.format(package, ', '.join(tags)))
Another thing that we could do to limit the burden of duplicated pkgs is to use symlinks instead of full copies. That will obviously blow up as soon as we need different spec files for SCL and non-SCL versions (but I don’t foresee that anytime soon).
Another contra symlinks is: the current Jenkins code will not detect that it needs to rebuild two packages.
But I don’t see a non-SCL version of rest-client in the repo? Anyways, after thinking a bit more, I think symlinks are not a good solution, as this would hinder automated builds (they would not show up in a git diff)
I think we can drop the foreman_api package altogether since it’s deprecated. The last update was in 2015 and I’m not even sure it supports the v2 API (nightly dropped v1).
