EPEL Questions about SCL during meeting (was: Anybody has something for agenda for Env-and-Stacks WG meeting today? (2014-09-09))
8:51 a.m.
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-201...
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-201...)
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-201...)
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
2:47 p.m.
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.)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:57 a.m.
On Thu, Sep 11, 2014 at 12:47 PM, Matthew Miller <mattdm(a)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...
).
9:48 a.m.
New subject: EPEL Questions about SCL during meeting
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
3519
days inactive
3524
days old
epel-devel@lists.fedoraproject.org
3 comments
3 participants
participants (3)
-
Dave Johansen -
Honza Horak -
Matthew Miller