Hide Forgot
Description of problem: rxvt-unicode currently bundles a private copy of the libev sources. It should instead build against the system libev. If that is not possible (for example because it builds a "specialized" ABI-incompatible libev), it could use the system libev sources instead of its own private copy. This is what is being done in other packages like tigervnc (which BuildRequires the xorg-x11-server-source subpackage package), and what I will be doing in ther perl-EV package once it gets approved (#448613) This obviously depends on bug #672153 being implemented, which would add a -source subpackage to the libev package, so I'm adding the relevant flag. For examples on how to implement it, see the proposed perl-EV SPEC file, or the tigervnc one. Basically, it all comes down to: BuildRequires: libev-source [... snip ...] # remove the bunled libev and use the system one instead rm -fr ./libev/* cp -a /usr/share/libev-source/* ./libev/* Subpackage name and source folder might change once bug #672153 is fixed, and I'll provide a definitive patch to the rxvt-unicode.spec file once it is the case.
I am inclined to close this as wontfix. I had a long talk about this with upstream a couple of month ago. If I understood it correctly they discourage system wide deployments of libev altogether. As you stated building from a -source package would be an alternative. However, even this is discouraged because of various reasons special or not to libev. In case of rxvt-unicode there would be no advantage to this as upstream is the same person as libev upstream. Did you discuss this at all with upstream developers?
(In reply to comment #1) > I am inclined to close this as wontfix. I had a long talk about this with > upstream a couple of month ago. If I understood it correctly they discourage > system wide deployments of libev altogether. It's not really that it is discouraged, it's that the system-wide binary libev is ABI-incompatible with the ones that perl-EV or rxvt-unicode build (although they come from identical source code). > As you stated building from a > -source package would be an alternative. However, even this is discouraged > because of various reasons special or not to libev. You mean discouraged in Fedora? If that is the case, do you have links to resources that explain why? (I will need to read them for my proposal of perl-EV). > In case of rxvt-unicode there would be no advantage to this as upstream is the > same person as libev upstream. This is also the case with the Perl EV module. > Did you discuss this at all with upstream developers? Yes, I talked about it with him as I'm trying to submit perl-EV to Fedora (see the review request in my previous comment). Upstream has actually advised me the libev-source subpackage approach, and he has also told me that rxvt-unicode was in the same case as perl-EV, which is why I opened this bug report in the first place. Debian is also looking into doing the -source subpackage trick: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507373 Out of curiosity, did you get an exception from FESCo for bundling the sources of libev in rxvt-unicode? If yes, then maybe I should stop bothering and ask simply them for an exception for perl-EV. :)