Packaging changes for libev in Rawhide

[Mathieu Bridon]

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.