In short, we need SCL 1.1 for EL6 and EL7 to support future features
(namely a Rails 4 migration). Currently CentOS 6 provides 1.0 in full,
and parts of 1.1 (not Rails 4) and SL 6 provides 1.1 in full. No builds
for CentOS or SL 7 are available yet.
http://softwarecollections.org is a public directory of SCLs linked to
Copr and the RHSCL team have published rebuilds of RHSCL 1.1 there for
EL6 and EL7 in separate repos. I think we need to begin using and
recommending scl.org for EL rebuilds if we're to depend on 1.1 and
enable the Rails 4 migration etc.
Currently for CentOS and SL, the installer will configure the SCL repos
by default, and for RHEL, users are told about enabling the RHSCL repo
as a pre-req.
I'd propose that to use scl.org, particularly as there are multiple
repos that need enabling (it's split per collection) that we:
v8314, and ror40+ruby200 when we begin to use them
Create a foreman-release-scl RPM which depends on them
Change the installer to install foreman-release-scl on CentOS/SL
Users upgrading would need to install the new package.
Or we could update the installer to configure the individual repos via
yumrepo resources, or by installing the release RPMs individually (I
sent a PR to scl.org to make the names more consistent). My only
concern with this is that we'll soon depend on three of them, so it
becomes harder to maintain in the installer.
Any preferences or more general thoughts/concerns about this direction?
Another possibility is that we contribute support to scl.org for
combining multiple repos into one, e.g. the "rhscl" user currently has
20-30 independent repos:
If we could create a single combined repo containing all of the EL6 or
EL7 packages then it would be easier to consume, so could be a manual
pre-req, or more easily configured from the installer.
It would also cut down on the proliferation of yum repos, which many
users understandably dislike.
···
On 10/09/14 12:10, Dominic Cleal wrote:
> I'd propose that to use scl.org, particularly as there are multiple
> repos that need enabling (it's split per collection) that we:
>
> 1. Include the scl.org "release" RPMs in our EL6/7 repos, e.g.
> https://www.softwarecollections.org/en/scls/rhscl/ruby193-el7/epel-7-x86_64/download/rhscl-ruby193-el7-epel-7-x86_64-1-2.noarch.rpm
> + v8314, and ror40+ruby200 when we begin to use them
> 2. Create a foreman-release-scl RPM which depends on them
> 3. Change the installer to install foreman-release-scl on CentOS/SL
>
> Users upgrading would need to install the new package.
>
> Or we could update the installer to configure the individual repos via
> yumrepo resources, or by installing the release RPMs individually (I
> sent a PR to scl.org to make the names more consistent). My only
> concern with this is that we'll soon depend on three of them, so it
> becomes harder to maintain in the installer.
>
> Any preferences or more general thoughts/concerns about this direction?
> Any preferences or more general thoughts/concerns about this direction?
I don't have any problem with separate SCL repos, it's just four of them
right? Since our installer can easily set them up, I don't expect users
to have problems with that (other than they can miss them all).
Two right now, three I think after the Rails 4 migration. I know we've
had some resistance and confusion in the past, which is why I raise it.
It might affect folks syncing repos locally more.
···
On 10/09/14 13:48, Lukas Zapletal wrote:
>> > Any preferences or more general thoughts/concerns about this direction?
> I don't have any problem with separate SCL repos, it's just four of them
> right? Since our installer can easily set them up, I don't expect users
> to have problems with that (other than they can miss them all).
