Based on the feedback, I have started the repository for this effort [1]
and opened an initial PR [2] that adds tooling and an initial set of
packages in order to ensure that tooling works. My goal is to get the
initial package and tooling reviewed and committed before moving on to
other packages.
+1 for 2.4. I believe currently it's beta in SCLo but I assume that
it'll be GA by the time we finish it and the RH-SCL version is already
GA.
On Tue, Nov 07, 2017 at 11:59:43AM -0500, Eric D Helms wrote:
One thing I didn't include as part of this discussion was a discussion of
the version of
One thing I didn't include as part of this discussion was a discussion of
the version of Ruby to use. Currently a Ruby 2.4 and Ruby 2.3 SCL exists
from the RHSCL team within CentOS. I propose we use Ruby 2.4 given that it
is latest and greatest. This is important, since the Rails SCL will have to
On Thu, Nov 2, 2017 at 6:24 AM, Daniel Lobato Garcia
wrote:
> I agree with all of that, definitely something to do in a different
> repository.
>
> Just one question, my understanding is that you prefer to do this (SCL)
> because we are uncertain of the time/effort required
On Thu, Nov 2, 2017 at 8:02 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:
> On Wed, Nov 01, 2017 at 02:00:29PM -0400, Eric D Helms wrote:
>
>> In a previous thread [1], we discussed building an SCL vs. vendorizing
>> gems
>> and the general consensus was to build an SCL.
On 11/02, Ewoud Kohl van Wijngaarden wrote:
> On Thu, Nov 02, 2017 at 11:24:26AM +0100, Daniel Lobato Garcia wrote:
> > Just one question, my understanding is that you prefer to do this (SCL)
> > because we are uncertain of the time/effort required for vendoring the
> > gems/npm
> > packages.
Big +1 to all of that.
I think COPR provides some own GPG keys and IIRC you can't override
those. It is possible to download packages from COPR and sign them
again with a custom key of course. That's perhaps your plan I guess.
Custom signatures is on COPR development TODO I think.
LZ
On Wed,
On Thu, Nov 02, 2017 at 11:24:26AM +0100, Daniel Lobato Garcia wrote:
Just one question, my understanding is that you prefer to do this (SCL)
because we are uncertain of the time/effort required for vendoring the gems/npm
packages. Given that long-term we would have to keep up building SCLs
I agree with all of that, definitely something to do in a different repository.
Just one question, my understanding is that you prefer to do this (SCL)
because we are uncertain of the time/effort required for vendoring the gems/npm
packages. Given that long-term we would have to keep up building