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 yum.theforeman.org and version them based on the Foreman release. For example, to create a http://yum.theforeman.org/releases/1.17/tfm-ror51 yum repository that holds Rails 5.1.4 and a http://yum.theforeman.org/releases/1.18/tfm-ror51 that holds Rails 5.1.6.
The packages would continue to be built on Copr but getting the repository copies onto yum.theforeman.org properly becomes the question I’d like feedback on.
Similar to Option 1 but we deploy a permanent yum.conf to yum.theforeman.org 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.
I’ve made a first pass at this by putting the various Rails SCL repositories on yum.theforeman.org. 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.
