Sorry to disagree, but segregation is standard practice and is far better then polluting /usr/include. Also, I have a package which has separate patches which I'm uncertain if upstream has adopted. https://github.com/apache/mesos/blob/master/3rdparty/libprocess/3rdparty/libev-4.15.patch Cheers, Tim ----- Original Message ----- > From: "Mathieu Bridon" <bochecha@xxxxxxxxxxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Tuesday, November 19, 2013 1:30:46 AM > Subject: Packaging changes for libev in Rawhide > > 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 -- Cheers, Tim -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
