[scl.org] How to migrate to CentOS builds
hhorak at redhat.com
Wed Jan 6 14:29:10 UTC 2016
On 01/06/2016 03:23 PM, Dominic Cleal wrote:
> On 06/01/16 14:17, Honza Horak wrote:
>> On 01/06/2016 02:39 PM, Dominic Cleal wrote:
>>> On 06/01/16 13:10, Honza Horak wrote:
>>>> On 01/05/2016 10:16 PM, Stephen John Smoogen wrote:
>>>>> On 5 January 2016 at 13:12, Honza Horak <hhorak at redhat.com> wrote:
>>>>> Is there a way to update that file to point to the new repository
>>>>> layout. That way when people do an update they will get pointed to the
>>>>> correct trees?
>>>> That was basically the second solution, just purely described. What I
>>>> meant by "empty RPMs that would include centos-release-scl-rh package",
>>>> I basically meant: rhscl-<scl>-epel-7-x86_64.noarch.rpm package would
>>>> not include the repo file, but would include Requires:
>>>> centos-release-scl-rh. By updating the
>>>> rhscl-<scl>-epel-7-x86_64.noarch.rpm file, users would get proper trees.
>>> This would only work on CentOS with Extras enabled though. I'm a little
>>> concerned about other rebuilds, e.g. Scientific or Oracle - would those
>>> users even want to use CentOS builds?
>> Well, if we speak about SCL packages available on centos mirrors, we
>> won't be able to maintain three copies anyway (one for RH users, one for
>> centos, one for other) and btw. at least Scientific has own rebuilds,
>> which I found just recently:
>> If the comment was just about how to enable the CentOS repositories in
>> Scientific or Oracle, that is something different. That would mean we'd
>> have to have a package in some different place than CentOS Extras, but
>> with the same content as the package `centos-release-scl-rh`.
> Yes, I meant this latter part - if the rhscl-* release RPM gains a
> dependency on the CentOS SCLo release package then the package will only
> install on CentOS unless it's available to RHEL and its other rebuilds
> (perhaps add it to the scl.org repos).
> I think I'd prefer to see the repos remain but either prevent new
> downloads of the release file or affix a large warning to the web UI to
> ensure people realise it's unmaintained.
Thanks for the feedback. I agree that the warning and at least hiding
the current repo file to prevent newcomers to use it would be probably
the safest and also much easier way.
More information about the SCLorg