Packaging changes for libev in Rawhide
Mathieu Bridon
bochecha at fedoraproject.org
Tue Nov 19 13:01:06 UTC 2013
On Tue, 2013-11-19 at 13:36 +0100, Michael Schwendt wrote:
> On Tue, 19 Nov 2013 15:30:46 +0800, Mathieu Bridon wrote:
> > 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).
That's in fact what is happening, which is why I'd like to get the
Fedora package inline with upstream and other distros.
> > 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 agree, but again, upstream refused it several times (Michal, the
original libev maintainer offered it, I did, the awesome developers did
too,...)
At this point, I really just want to have the Fedora package inline with
upstream, so that consumers of the library use it the same way
everywhere.
> 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).
So, libev's ev.h and libevent's event.h might very well be installed on
the same system, in the case of a developer working on two different
applications, or on something like libverto (a wrapper for different
event loops).
But libev's event.h and libevent's event.h should not.
> But in general, conflicts bear a risk and may lead to future problems,
> and I would have opened this thread on packaging@ list instead.
Oh? Should we move there now?
I thought devel@ was better, as it needed to reach the maintainers of
the packages which build against libev.
> > 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.
Right, it's certainly unorthodox.
The problem is that libev is actually intended to be bundled by
upstream, and perl-EV is made by the same people.
As a result, they **really** don't want to unbundle libev from perl-EV.
The approach I followed was a compromise, it's definitely not the most
desirable outcome.
> Such a dependency ought to be tracked in a special way, preferably with
> official blessing from the FPC.
I didn't pass it through FPC because there are a few precedents. The one
I inspired myself from is xorg-x11-server-source.
I assumed that given there were already quite a few of these, it was an
accepted practice.
Did I assume wrong?
--
Mathieu
More information about the devel
mailing list