Spec URL: https://download.copr.fedorainfracloud.org/results/pvalena/rubygems/fedora-rawhide-x86_64/02052496-rubygem-ffi-rzmq-core/rubygem-ffi-rzmq-core.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/pvalena/rubygems/fedora-rawhide-x86_64/02052496-rubygem-ffi-rzmq-core/rubygem-ffi-rzmq-core-1.0.7-1.fc35.src.rpm Description: This gem provides only the FFI wrapper for the ZeroMQ (0mq) networking library Fedora Account System Username: jackorp Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=63127361 This package is one of the new dependencies required for cucumber update.
Can we depend on versioned library "so file" instead? (That's the preferred way of specifying dependencies AFAIK.) Like in this commit: https://github.com/fedora-distgit/rubygem-ffi-rzmq-core/commit/c0729fb1c3a2f4c5c225addfd3e07bb8de490f1b#diff-4fe66120347be998c33ea765bccd78806cd3ebf6cc7eafef37bf2841fabbb0ec (Yes, we do want that, on purpose.) As there's no binary extension, ``` BuildArch: noarch ``` we need to specify so arch-specific dependencies with richdeps (if libffi...). On the upside, there's no need for the patch.
(In reply to Pavel Valena from comment #1) > Can we depend on versioned library "so file" instead? (That's the preferred > way of specifying dependencies AFAIK.) > > Like in this commit: > https://github.com/fedora-distgit/rubygem-ffi-rzmq-core/commit/ > c0729fb1c3a2f4c5c225addfd3e07bb8de490f1b#diff- > 4fe66120347be998c33ea765bccd78806cd3ebf6cc7eafef37bf2841fabbb0ec > (Yes, we do want that, on purpose.) Yes, you are right, depending on libzmq.so.5 like that does what we want. > > As there's no binary extension, > ``` > BuildArch: noarch > ``` Yes, that is specified correctly. > we need to specify so arch-specific dependencies with richdeps (if > libffi...). On the upside, there's no need for the patch. There is because the library is using hardcoded to search for `libzmq.so`[0] which is only in the `zeromq-devel` and that package pulls in many unnecessary devel dependencies (and libzmq.so is not present not even via symlink in the bare `zeromq` package). [0] the line gets expanded into `libzmq.so` specifically, so if we require `libzmq.so.5` in spec it would pull in zeromq, but it would not work. [0] https://github.com/chuckremes/ffi-rzmq-core/blob/master/lib/ffi-rzmq-core/libzmq.rb#L39
update spec: https://download.copr.fedorainfracloud.org/results/pvalena/rubygems/fedora-rawhide-x86_64/02058689-rubygem-ffi-rzmq-core/rubygem-ffi-rzmq-core.spec updated srpm: https://download.copr.fedorainfracloud.org/results/pvalena/rubygems/fedora-rawhide-x86_64/02058689-rubygem-ffi-rzmq-core/rubygem-ffi-rzmq-core-1.0.7-1.fc35.src.rpm
(In reply to Jarek Prokop from comment #2) > (In reply to Pavel Valena from comment #1) </snip> > > we need to specify so arch-specific dependencies with richdeps (if > > libffi...). On the upside, there's no need for the patch. > > There is because the library is using hardcoded to search for `libzmq.so`[0] > which is only in the `zeromq-devel` and that package pulls in many > unnecessary devel dependencies (and libzmq.so is not present not even via > symlink in the bare `zeromq` package). Ah, sorry, I didn't check the patch and thought it's doing something different. Yes, we don't want zeromq-devel. Isn't that a bug, though? Denis, could you comment, please? > > [0] the line gets expanded into `libzmq.so` specifically, so if we require > `libzmq.so.5` in spec it would pull in zeromq, but it would not work. Jarku, if it's a correct soname, can you create a PR upstream? > > > [0] > https://github.com/chuckremes/ffi-rzmq-core/blob/master/lib/ffi-rzmq-core/ > libzmq.rb#L39
I'm taking this review.
(In reply to Pavel Valena from comment #4) > (In reply to Jarek Prokop from comment #2) > > (In reply to Pavel Valena from comment #1) > </snip> > > > we need to specify so arch-specific dependencies with richdeps (if > > > libffi...). On the upside, there's no need for the patch. > > > > There is because the library is using hardcoded to search for `libzmq.so`[0] > > which is only in the `zeromq-devel` and that package pulls in many > > unnecessary devel dependencies (and libzmq.so is not present not even via > > symlink in the bare `zeromq` package). > > Ah, sorry, I didn't check the patch and thought it's doing something > different. Yes, we don't want zeromq-devel. Isn't that a bug, though? > > Denis, could you comment, please? Hmm, looks like at least according to ruby-ffi[1] wiki it does not seem like a bug on our end. > > > > > [0] the line gets expanded into `libzmq.so` specifically, so if we require > > `libzmq.so.5` in spec it would pull in zeromq, but it would not work. > > Jarku, if it's a correct soname, can you create a PR upstream? I think it should look not only for `libzmq.so` (which seems like the preferred upstream approach) but also for `libzmq.so.5`. I'll open a PR upstream and add a comment with a PR link to the spec once I do so. > > > > > > > [0] > > https://github.com/chuckremes/ffi-rzmq-core/blob/master/lib/ffi-rzmq-core/ > > libzmq.rb#L39 [1] https://github.com/ffi/ffi/wiki/Loading-Libraries#linux-packages
(In reply to Jarek Prokop from comment #6) > I'll open a PR upstream and add a comment with a PR link to the spec once I > do so. Thanks!
I opened upstream PR [0] and referenced it in the specfile. There is no functional change in the package, just the reference. updated spec: https://download.copr.fedorainfracloud.org/results/pvalena/rubygems/fedora-rawhide-x86_64/02059349-rubygem-ffi-rzmq-core/rubygem-ffi-rzmq-core.spec updated srpm: https://download.copr.fedorainfracloud.org/results/pvalena/rubygems/fedora-rawhide-x86_64/02059349-rubygem-ffi-rzmq-core/rubygem-ffi-rzmq-core-1.0.7-1.fc35.src.rpm [0] https://github.com/chuckremes/ffi-rzmq-core/pull/18
I just wonder, do we really need this package? As far as I understand, this is required to satisfy Cucumber test requirements. I realize this can be also runtime dependency if chosen, but we don't have this use case, or do we?
(In reply to Vít Ondruch from comment #9) > I just wonder, do we really need this package? As far as I understand, this > is required to satisfy Cucumber test requirements. I realize this can be > also runtime dependency if chosen, but we don't have this use case, or do we? IMHO it comes down to if we want to provide that functionality by default. We can just package protobuf (with disabled zmq support and maybe some message), and if users will want to use the zeromq capability they will have to install the gem and the library.
(In reply to Jarek Prokop from comment #10) > IMHO it comes down to if we want to provide that functionality by default. We want just enough functionality to be able to update Cucumber. If somobody needs some additional functionality, the zmq can be added later). > We can just package protobuf (with disabled zmq support and maybe some > message), and if users will want to use the zeromq capability they will have > to install the gem and the library. But this is the default state, isn't it? zmq is not default runtime dependency of protobug AFAIK.
(In reply to Vít Ondruch from comment #11) > (In reply to Jarek Prokop from comment #10) </snip> > > But this is the default state, isn't it? zmq is not default runtime > dependency of protobug AFAIK. It is not a default runtime. Let's hold on with this review (and the subsequent rubygem-ffi-rzmq rhbz#1935699 [0]), I will investigate how much does rubygem-protobuf actually need to be able to pass cucumber-messages tests. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1935699
I am closing this request. This package won't be required in the end.