Packaging changes for libev in Rawhide
Tim St Clair
tstclair at redhat.com
Tue Nov 19 17:43:46 UTC 2013
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
More information about the devel
mailing list