EPEL Questions about SCL during meeting

Honza Horak hhorak at redhat.com
Mon Sep 15 14:48:48 UTC 2014

On 09/12/2014 04:57 PM, Dave Johansen wrote:
> On Thu, Sep 11, 2014 at 12:47 PM, Matthew Miller
> <mattdm at fedoraproject.org <mailto:mattdm at fedoraproject.org>> wrote:
>     On Wed, Sep 10, 2014 at 03:51:00PM +0200, Honza Horak wrote:
>     > However, there are and will be cases where somebody would like to
>     > create a non-SCL RPM depended on a software collection, which is
>     > something not solved properly yet and the solution might be quite
>     > different from collection to collection.
>     This makes me kind of scared. I'm all for the first sort of software
>     collection, but I think limiting this helps constrain the problem set.
>     (Although I don't think such packages should be limited from, eg, Fedora
>     Playground.)
> I'm not sure how/if this matters on Fedora, but for EL, being able to
> use devtoolset would be a big gain and would allow for inclusion of
> packages that require a newer compiler than gcc 4.4 that comes with RHEL
> 6 (
> https://lists.fedoraproject.org/pipermail/epel-devel/2013-September/008737.html
> ).

Right, devtoolset is one of the examples where I see the point of 
non-SCL package depended on SCL.

Dynamic languages are a bit different story, since (with a bit of 
abstraction) depended packages are often libraries that extend 
functionality of the language ecosystem and thus we want to install them 
directly into the ecosystem.

But if some package is created strictly above the ecosystem, it does not 
have to care if the interpreter comes from SCL package or not and it 
will work fine as soon as the interpreter matches the required version.

Or, on the other hand, requiring package always as SCL for all 
SCL-depended packages does not seem to make things easier.


More information about the env-and-stacks mailing list