Packaging changes for libev in Rawhide

[Michael Schwendt]

On Tue, 19 Nov 2013 15:30:46 +0800, Mathieu Bridon wrote:

> 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/

That's a common way to resolve such a conflict:
https://fedoraproject.org/wiki/Packaging:Conflicts#Header_Name_Conflicts

However, it gets problematic when such a change is not accepted by
upstream. Developers, who base their work on Fedora's *-devel packages,
will publish something that's incompatible with pristine upstream
releases. Unless they make their software detect the different install
locations (or renamed libs even).

>   2. we ship a pkgconfig file, which upstream does not want

A .pc file only adds value, if every API consumer uses pkg-config. Where
pkg-config is not used, locating moved headers becomes troublesome, and
lazy developers would simply hardcode search paths in Makefiles, or
worse, in #include-statements.

> 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.

To be fair, a single bug report doesn't have much weight. It's easy enough
to list the package contents and notice where the headers are stored.
The differences between multiple distributions (as well as upstream)
are not so good, however.

> 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.

Agreed. Though, this is more of a problem for the API consumers, who ought
to support not just Fedora's libev packages but also pristine upstream
libev. Afterall, their software would only build for Fedora.

> 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)

Seems plausible.

Personally, I don't mind explicitly conflicting -devel packages,
especially not if they are unlikely to be present in the same buildroot
(and libev's event.h is a libevent compatibility header).
But in general, conflicts bear a risk and may lead to future problems,
and I would have opened this thread on packaging@ list instead.

>   * Drop our pkgconfig file.

Upstream really doesn't like pkgconfig.

> Does anybody have any comment, or objection?

This one is weird:
https://bugzilla.redhat.com/672153

In order to make the "perl-EV" package not use a bundled "libev" source,
you build a "libev-source" subpackage that perl-EV adds as BuildRequires.
In other words, perl-EV now still bundles libev, but only indirectly. An
update of libev does not affect perl-EV until perl-EV is rebuilt. libev has
been updated from 4.11 to 4.15 in Fedora, but perl-EV has not been rebuilt.

Such a dependency ought to be tracked in a special way, preferably with
official blessing from the FPC.