On 09/12/2014 04:57 PM, Dave Johansen wrote:
On Thu, Sep 11, 2014 at 12:47 PM, Matthew Miller
<mattdm(a)fedoraproject.org <mailto:mattdm@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/00873...
).
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