Re: Packaging changes for libev in Rawhide
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