On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Tue, 23 Aug 2016 14:21:24 +0100
Karanbir Singh <mail-lists(a)karan.org> wrote:
> On 22/08/16 18:30, Jason L Tibbitts III wrote:
> >>>>>> "DJ" == Dave Johansen
<davejohansen(a)gmail.com> writes:
> >
> > DJ> devtoolset is designed to do all of this and is already done,
> > DJ> so it seems that the only advantage to putting it in EPEL
> > DJ> itself would be to reduce the number of repos during build
> > DJ> time.
> >
> > So is devtoolset something I get access to as a CentOS user? How
> > do I build these packages myself (i.e. in mock)?
>
> you should be able to 'yum install centos-release-scl' on a CentOS
> Linux machine and get access to all the SCLs
Yeah, but if we enable that for EPEL builds, we are going to get all
SCLs right? So, people could start depending on them at runtime instead
of just install time.
I'm not opposed to devtoolset, but I don't think we want to allow
runtime scls without actual scl guidelines.
I seem to remember that Fedora didn't allow SCLs because there was some
compatibility problem or something of the sort. Do you know the details or
what the current state is?
Also, RedHat has been pushing devtoolset pretty hard. The response to a few
bugzillas has even been "use devtoolset because the issue is fixed there
and we're not going to fix the system gcc/libc/etc". So it seems like
allowing SCLs in Fedora/EPEL makes sense and fits with the direction of
RHEL in general.