[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: The v4 dependency chain - issues with therubyracer and v8



> On Jul 30, 2014, at 09:58, Troy Dawson <tdawson redhat com> wrote:
> 
> Hi Harrison,
> Where are people getting their versions of ruby193-rubygem-therubyracer?
> And what version are they getting?
> 
> I ask that because the latest version of ruby193-rubygem-therubyracer
> (ruby193-rubygem-therubyracer-0.11.0-0.8.beta5.el6) has exactly what you
> are asking for.
> 
> # rpm -qp --requires
> ruby193-rubygem-therubyracer-0.11.0-0.8.beta5.el6.x86_64.rpm | grep v8
> libv8.so.v8314-3.14.5()(64bit)
> v8314-v8
> 
> That version is in both the nightly and release 4 dependency repo.

That's good to know. Thanks for clarifying.

> 
> Troy
> 
> On 07/30/2014 08:46 AM, N. Harrison Ripps wrote:
>> Hey all-- I am hoping to consolidate discussion of the dependency
>> chain for Origin v4 under one thread; there are at least two others
>> right now and they are covering very similar ground.
>> 
>> Here's some perspective on what is happening.
>> 
>>> From the ruby193 software collection (SCL), we use the
>>> ruby193-rubygem-therubyracer RPM. This gem depends on an RPM from a
>>> different SCL, specifically, the v8314-v8 RPM from the v8314 SCL.
>>> And from our perspective, this would all "just work" if the
>>> ruby193-rubygem-therubyracer included v8314-v8 as a specific
>>> dependency. However, it doesn't. The answer to "why" is one that I
>>> hope to have soon, but in the meantime, there are other ways to
>>> solve the problem.
>> 
>> I think the best short-term way to solve this issue will be for us to
>> instead make the v8314-v8 RPM a dependency of our own RPMs,
>> specifically the ones that also depend upon therubyracer:
>> 
>> * openshift-origin-console 
>> * rubygem-openshift-origin-console
>> * openshift-origin-admin-console
>> * rubygem-openshift-origin-admin-console
>> 
>> A number of you have been looking at other workarounds, and my main
>> concern with those is that they won't survive a "yum update" down the
>> road.
>> 
>> So hopefully this answers some questions around why this is happening
>> and what we are planning to do to solve the problem. Please feel free
>> to follow up with your own findings, or any questions or concerns
>> that you may have. As always, I am really appreciative of the folks
>> who take the time to report on these matters, so thank you very much
>> for bringing your findings to the community!
>> 
>> --Harrison
>> 
>> 
>> _______________________________________________ dev mailing list 
>> dev lists openshift redhat com 
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>> 
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]