Bug 1049554 - adding CFLAGS=-DEV_CHILD_ENABLE=0 for compilation of libev.
Summary: adding CFLAGS=-DEV_CHILD_ENABLE=0 for compilation of libev.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: libev
Version: rawhide
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Mathieu Bridon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-07 18:12 UTC by Timothy St. Clair
Modified: 2014-02-27 19:37 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-27 19:37:14 UTC


Attachments (Terms of Use)

Description Timothy St. Clair 2014-01-07 18:12:59 UTC
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%

Comment 1 Mathieu Bridon 2014-01-08 01:42:07 UTC
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...

Comment 2 Timothy St. Clair 2014-01-08 02:54:04 UTC
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.

Comment 3 Mathieu Bridon 2014-01-08 03:13:41 UTC
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. :(

Comment 4 Mathieu Bridon 2014-01-08 03:15:17 UTC
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

Comment 5 Timothy St. Clair 2014-01-08 13:55:51 UTC
There are options for source / forced rebuild packaging, let me dig up the ref.

Comment 6 Timothy St. Clair 2014-01-08 19:55:30 UTC
It seems like this qualifies as a CopyLib exception: 
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs

Comment 7 Mathieu Bridon 2014-01-09 03:58:47 UTC
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.

Comment 8 Mathieu Bridon 2014-01-24 04:47:17 UTC
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.

Comment 9 Timothy St. Clair 2014-01-24 15:42:34 UTC
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.

Comment 10 Timothy St. Clair 2014-01-31 14:13:34 UTC
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.

Comment 11 Mathieu Bridon 2014-01-31 14:53:43 UTC
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.

Comment 12 Timothy St. Clair 2014-02-27 17:06:40 UTC
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}

Comment 13 Timothy St. Clair 2014-02-27 19:35:47 UTC
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.

Comment 14 Timothy St. Clair 2014-02-27 19:37:14 UTC
For those that stumble upon *this and have a similar experience references will be documented in mesos.spec.


Note You need to log in before you can comment on or make changes to this bug.