Hi, I would like to finally fix this bug in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=985610 Basically, our libev package diverges from upstream in two ways: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ 2. we ship a pkgconfig file, which upstream does not want I'm not happy with these Fedora-specific changes, and upstream is completely uninterested in them. It's confusing users who don't find the headers where they expect them, as demonstrated by this bug report. Worst of all, it's causing changes in software consuming libev, which have often had to be modified for the Fedora-specific change in libev. Those changes were sometimes made in the respective upstreams, but most often in additional Fedora-specific changes. I've been talking to upstream libev, and they really don't want the changes we made. They'd be much happier if we were packaging libev the way Debian is, as that's how they intended libev to be used. So I'd like to follow upstream libev wishes, and stop confusing everybody with our Fedora-only changes. My plan is to do the following in Rawhide (the future Fedora 21) : * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) * Drop our pkgconfig file. Here is the list of packages I could find with a build requirement on libev: $ repoquery --enablerepo=\*source --archlist=src --whatrequires 'pkgconfig(libev)' libev-devel awesome-0:3.5.1-8.fc20.src i3-0:4.6-1.fc20.src i3lock-0:2.5-2.fc20.src libverto-0:0.2.5-3.fc20.src ocaml-lwt-0:2.4.2-3.fc20.src picviz-0:0.6-12.fc20.src rubygem-passenger-0:4.0.18-2.fc20.src rubygem-passenger-0:4.0.18-4.fc20.src spectrum-0:1.4.8-11.fc20.src stud-0:0.3-4.20120814git.fc20.src weighttp-0:0.3-5.fc20.src I'll fix weighttp, as it is my package, but I can't do much about the other ones. I'm adding a breakdown of how these packages use libev and what needs to be done for them at the end of this email. Does anybody have any comment, or objection? Cheers, -- Mathieu -------------------- awesome ------- Our package has some downstream patches to require our Fedora-only pkgconfig file for libev. Making it build-require libev-devel instead and dropping this downstream patch should be enough. i3 -- Nothing should need to be done here. Upstream checks for libev with pkg-config, but it ignores errors. And once I move the libev headers in /usr/include, then they'll be found anyway. i3lock ------ The spec file calls pkgconfig to find the libev headers. This should just be removed, and the package should build just fine, as intended by upstream. libverto -------- Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. ocaml-lwt --------- The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. picviz ------ The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. rubygem-passenger ----------------- Upstream hardcodes -I/usr/include/libev in the cflags, which is only needed with our current libev package in Fedora, nowhere else. Anyway, the package should just build without any change once I move the libev headers to /usr/include. spectrum -------- Upstream searches for the ev.h header in various folders, so things should continue to work without a change. stud ---- Our package has a patch to hardcode -I/usr/include/libev in the CFLAGS. That can be dropped. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
