Description of problem: I have a dependent package(mesos) that depends on libev compilation with a switch disabled, but I'm uncertain if their are any sub-dependencies that require, or expect this behavior. Version-Release number of selected component (if applicable): 4.15 How reproducible: 100%
So, it seems that each libev consumer needs libev to have been built in a certain (sometimes incompatible) way. perl-EV is from the same upstream authors as libev, and it just bundles libev because it needs it built in a certain way: https://fedorahosted.org/fpc/ticket/369 Now mesos seems to need it built in another way. I'm not sure what to do here...
Options may be to consult upstream around making less options compile time vs. run-time with optional input arguments. void foo (int bar, int opt1=1, opt2=1) etc. or possibly via an initialization structure. Honestly there are numerous approaches, that don't force compile time constraints.
Sure, but it doesn't seem like upstream wants that. As I mentioned, perl-EV is from the same upstream as libev, and they bundle libev so it's built just the way they need it. Another example, rxvt-unicode is also from the same upstream as libev, and they bundle it so it's built just the way they need it. (I didn't check, but I wouldn't be surprised if they built it in a different way from perl-EV). I spent some time talking to them in the past, and they consider libev to be similar to these C++ libraries where everything is in the headers. (and as such, which are bundled at build-time through #include, which offer many build=time options, etc...) They designed libev to be that way, which is proving more and more to be incompatible with the Fedora policies. One way out is to get upstream libev to change their practices, sure. Another way out is to change the Fedora policies. I personally would prefer it if libev were more in line with Fedora policies, if it could be built once and then linked everywhere... But upstream disagrees. Right now, I'm refraining on doing anything with the perl-EV package (and as such, it is kept to an older version) until the FPC discussion [1] leads to a conclusion. I guess we should broaden the FPC discussion from just perl-EV to the general issue of libev and its consumers, of which mesos is one. I honestly don't know what else to do with this package. I could disable the feature as you requested, sure. And then someone else might come and ask for it to be re-enabled. :(
Sorry, I forgot to add the link to my last comment. (but then it's the same as the one I had given in comment 1). [1] https://fedorahosted.org/fpc/ticket/369
There are options for source / forced rebuild packaging, let me dig up the ref.
It seems like this qualifies as a CopyLib exception: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs
I asked in the FPC ticket, we'll see. If they agree, that would make it easier for perl-EV, rxvt-unicode and mesos, at least. Also, it means I could drop the libev-source subpackage. The next FPC meeting is tomorrow: https://lists.fedoraproject.org/pipermail/devel/2014-January/193637.html I won't be able to attend though, it's at 1am in my timezone.
So, FPC found the -source thing acceptable. Does that work for you? I.e, can you add to your spec: BuildRequires: libev-source And then in %prep, just replace the bundled libev by the ones coming from the libev-source package? For example, this is how I'm doing it in perl-EV: http://pkgs.fedoraproject.org/cgit/perl-EV.git/tree/perl-EV.spec#n40 (Of course, if you thing that's not the right way to do it, I'd be interested in your feedback so I improve perl-EV in the process) If that solution works for you, then I'll just close this as NOTABUG.
I think this should be ok, but you probably need to open BZ's on all deps. Also, I would be sure not to pollute /usr/include with ev.h now.
In following up on *this: ------------------------------------- repoquery --whatrequires libev awesome-0:3.5.1-8.fc20.x86_64 i3-0:4.6-1.fc20.x86_64 i3lock-0:2.5-2.fc20.x86_64 libev-devel-0:4.15-1.fc20.i686 libev-devel-0:4.15-1.fc20.x86_64 libverto-libev-0:0.2.5-3.fc20.i686 libverto-libev-0:0.2.5-3.fc20.x86_64 ocaml-lwt-0:2.4.2-3.fc20.x86_64 ocaml-lwt-0:2.4.2-4.fc20.x86_64 picviz-0:0.6-12.fc20.i686 picviz-0:0.6-12.fc20.x86_64 picviz-plugin-pngcairo-0:0.6-12.fc20.x86_64 rubygem-passenger-native-0:4.0.18-2.fc20.x86_64 spectrum-0:1.4.8-11.fc20.x86_64 stud-0:0.3-4.20120814git.fc20.x86_64 weighttp-0:0.3-5.fc20.x86_64 ------------------------------------- You may want to check on how the over packages depend on libev.
Not sure why you changed the summary, given that the copylib option was completely refused by the FPC... As for the other things depending on libev, they'd really need their own bugs, rather than continuing to use this one, so I'm going to just close it now, as there isn't any need to add that CFLAGS any more. (In reply to Timothy St. Clair from comment #9) > Also, I would be sure not to pollute /usr/include with ev.h now. I don't intend to deviate from upstream on this point, as we do for any other software. There just aren't any advantages to it that would outweigh the costs of that deviation.
So I'm reopening *this issue, because it's extremely odd to have to require a -source package and rebuild those sources as part of my build and bundle into my package. FWIW , I think we should call out what the impact is, if any, of adding the compilation flag as a default, which was the original intent of the ticket. e.g. - %build export CFLAGS="$RPM_OPT_FLAGS -DEV_CHILD_ENABLE=0" %configure --disable-static --with-pic make %{?_smp_mflags}
ok, I talked with other developers and I'll retract the reopen. -DEV_CHILD_ENABLE=0 offloads the reaping where libev would do it by default. I'll have to live with the -source package and patch to handle.
For those that stumble upon *this and have a similar experience references will be documented in mesos.spec.