https://bugzilla.redhat.com/show_bug.cgi?id=1114146
--- Comment #4 from Vít Ondruch <vondruch(a)redhat.com> ---
(In reply to Julian C. Dunn from comment #3)
So I have already had this discussion with upstream. The vendoring
(or not)
of the C library is all within the separate libyajl2 gem, to abstract that
away.
Yes, and that is the point. This is one level of abstraction too much.
If the vendored library would be part of the ffi-yajl, as that was actually
case for the yajl-ruby, that would be OK.
If that would be no hard dependency, that would be OK as well. You can take a
look at bson and bson_ext for example, or at multi_json. Every of this library
has dependencies. If they are not fulfilled, warning or error is issued.
I can separately package that gem as rubygem-libyajl2 with the
vendoring turned off (it's supported by upstream) instead of doing it the
way I have done; would that be acceptable, to maintain the existing
dependency tree?
With sad hearth. Since I am afraid it will end up as therubyracer with its v8
dependency :/
The only reason I did it this way is because at this point the
rubygem-libyajl2 package becomes a complete no-op and is only used to
satisfy gem deps.
Yes, I understand your reasons.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component