Packaging changes for libev in Rawhide

[Tim St Clair]

Sorry to disagree, but segregation is standard practice and is far better then polluting /usr/include. 

Also, I have a package which has separate patches which I'm uncertain if upstream has adopted. 

https://github.com/apache/mesos/blob/master/3rdparty/libprocess/3rdparty/libev-4.15.patch

Cheers,
Tim

 

----- Original Message -----
> From: "Mathieu Bridon" <bochecha at fedoraproject.org>
> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> Sent: Tuesday, November 19, 2013 1:30:46 AM
> Subject: Packaging changes for libev in Rawhide
> 
> 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.
> 
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
Cheers,
Tim