EPEL Questions about SCL during meeting (was: Anybody has something for agenda for Env-and-Stacks WG meeting today? (2014-09-09))

[Honza Horak]

On 09/09/2014 09:57 AM, Honza Horak wrote:
> I've quickly look at the EPEL meeting minutes from the last Friday, for
> anybody else interesting:
> http://meetbot.fedoraproject.org/epel/2014-09-05/epel-weeklym-meeting-2014-0...

There were some ideas worth bringing to attention that I would try to 
react to:

16:43:25 <dgilmore> stahnma: not sure we can allow depending of software 
collections
(http://meetbot.fedoraproject.org/epel/2014-09-05/epel-weeklym-meeting-2014-0...)

Just from a technical POV (not taken into account if we allow that in 
Fedora/EPEL/whereever) -- a common use case now is that if some package 
depends on some software collection, this package either is build in the 
same or in a depended software collection.

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.

16:47:43 <Evolution> smooge: where's the upstream for scls?
16:47:51 <Evolution> it's damned sure not softwarecollections.org
16:47:52 <smooge> softwarecollections.org I believe
16:48:07 <Evolution> it *should* be that, but it's not.
(http://meetbot.fedoraproject.org/epel/2014-09-05/epel-weeklym-meeting-2014-0...)

For the tooling (scl-utils), the upstream is at
https://fedorahosted.org/SoftwareCollections

For the collections packages (packages with scl macros defined) the 
upstream indeed is supposed to be at softwarecollections.org but I must 
admit we are not there yet (it's quite fresh project) -- there are still 
pieces missing like RPM sources in git, bug tracking or active 
development ahead of already released RHSCL.

But there is definitely not any other upstream url.

Cheers,
Honza

[Matthew Miller]

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.)

[Dave Johansen]

On Thu, Sep 11, 2014 at 12:47 PM, Matthew Miller 
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.h...
).

EPEL Questions about SCL during meeting

[Honza Horak]

On 09/12/2014 04:57 PM, Dave Johansen wrote:
> On Thu, Sep 11, 2014 at 12:47 PM, Matthew Miller
> <[e-mail] > 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.h...
> ).

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.

Honza