Packaging changes for libev in Rawhide

Simo Sorce simo at
Sat Nov 23 18:47:49 UTC 2013

On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote:
> Hi,
> I would like to finally fix this bug in Fedora:
> 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.

Libverto builds against both libevent and libev being a event loop
abstraction library, if you make libev and libevent conflict libeverto
cannot be built anymore.

It makes not sense to make libev and libevent conflict, even if just in
development headers.

If upstream can;t see it then the distribution has to deal with it,
which is what has been done with the changes you noted.

Big -1 to revert those changes and breaking libverto in the process for
no good reason whatsoever.

CCed Nathaniel which is libverto's author.


Simo Sorce * Red Hat, Inc * New York

More information about the devel mailing list