https://bugzilla.redhat.com/show_bug.cgi?id=1114146
--- Comment #5 from Julian C. Dunn jdunn@aquezada.com --- (In reply to Vít Ondruch from comment #4)
(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.
Well, upstream has reasons for doing it that way (wanted to divorce building native extension for vendored yajls from the FFI wrapper, because the native extension needs to be built on many different esoteric platforms). But I already had conversations with them & they are not willing to change it, so here we are.
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 :/
I have addressed the concerns by packaging rubygem-libyajl2 separately and removed the invasive patches. I also took the opportunity to upgrade to the latest version of ffi-yajl.
SRPM: https://jdunn.fedorapeople.org/rubygem-ffi-yajl/rubygem-ffi-yajl-1.1.0-1.fc2... SPEC: https://jdunn.fedorapeople.org/rubygem-ffi-yajl/rubygem-ffi-yajl.spec