Versioning tfm-ror51 SCL on

To allow more flexible releases and updates to the Rails packaging stack we are maintaining the proposal has been to copy tfm-ror51 Copr repositories to and version them based on the Foreman release. For example, to create a yum repository that holds Rails 5.1.4 and a that holds Rails 5.1.6.

The packages would continue to be built on Copr but getting the repository copies onto properly becomes the question I’d like feedback on.

Option 1

  1. Create routine or push button Jenkins job
  2. Deploy a customized yum.conf to
  3. Run reposync to sync contents to proper location
  4. Delete yum.conf

Option 2

Similar to Option 1 but we deploy a permanent yum.conf to that is managed by puppet with a routine reposync.

Both of these options will still require us to create version specific Copr repositories. That is to say, we will still need a tfm-ror51-5.1.4 and a tfm-ror51-5.1.6 to prevent accidentally updating the wrong repository.

The more I investigate and deal with these Rails updates, I also wonder if we’d been better served in the future creating a single RPM that contains the entire Rails stack.

My initial feeling is that we should keep it simple. That means a manual sync is fine.

There is also a third option: a shared repository with multiple rails versions in it. Foreman would then depend on = 5.1.4 or = 5.1.6. Not sure how well that would work in practice.

1 Like

A side benefit of hosting it on is that people like me who run their foreman server IPv6-only can retrieve all repositories.

I’ve made a first pass at this by putting the various Rails SCL repositories on This places the repositories organized by Rails version. The following questions have been raised thus far on how we structure this:

  • Should we instead group by foreman version? For example:


I’m not sure the extra level is needed. I’d propose:

  • /rails/foreman-1.17/el7/x86_64
  • /rails/foreman-1.18/el7/x86_64

That way we can bump it from 5.1.4 to 5.1.6 without users noticing. This may be needed in case we need an upstream bugfix or security fix. I’d like to avoid users needing to change their repos.

I don’t follow why users would need to change their repos. We control the repository file that gets laid down with Foreman via the repository RPM. So whether we have it as foreman-1.17 or 5.1.4 we still control when and how users get Rails updates unless I am missing something.

I think I’d like to support the use case of yum update and you get the latest foreman. If we need to change the URL, then it becomes yum update foreman-release && yum update unless I’m missing something.

Ahh you are supposing a Rails upgrade during the z-stream, which while unlikely could happen. Fair enough.

Exactly. I should have been a bit clearer about that.