Packaging changes for libev in Rawhide

Michael Schwendt mschwendt at
Wed Nov 20 11:17:51 UTC 2013

On Wed, 20 Nov 2013 11:24:34 +0800, Mathieu Bridon wrote:

> > The current packaging approach is circumventing the packaging policies:
> >
> > 
> > perl-EV does not use the system libev. No real "unbundling" has been
> > achieved by replacing the bundled source with another copy at build-time.
> > A bug-fix (or security-fix) of libev would not affect perl-EV without
> > rebuilding perl-EV. Even rebuilding perl-EV isn't safe. There's no strict
> > dependency, but only:
> > 
> >   BuildRequires:  libev-source >= %{version}
> > 
> > As a result, it is not ensured that a rebuild picks up the latest patched
> > libev-source. Even a buildroot override would be needed.
> I know all that. :)

That makes it more difficult to answer.

In the original review request, it was mentioned to "request an exemption
from FESCo":

In the ticket, you mention:
 | [...] the bundled ones have always been identical to the system
 | ones we use to build our libev package), but in that the built
 | binaries are ABI-incompatible.

The ticket has been closed over a year later to restart with another review:

In that ticket, the missing unbundling has not been commented on by the
reviewer. There is no explicit acknowledgement either. You explain:
 | There's a bundled copy of libev in the source RPM.
 | At build-time, I remove this folder and use instead the sources coming
 | from the Fedora libev-source package, to avoid building against the
 | bundled copy (this is what is done by other packages such as tigervnc
 | that uses the sources from Xorg).

Effectively, and repeating that cannot be avoided, you restore the bundled
sources, an no "unbundling" is done. More precisely, you replace the
bundled sources with a copy that may be different (especially for the case
that "libev" is at a different version than what is bundled with "perl-EV").

Nobody care foresee how long the sources will be "identical". Currently,
upstream perl-EV in CVS does not include a bundled libev, but refers to the
separate libev project in CVS. Anyone, who checks out perl-EV from CVS
will need to check out libev, since the bundling is only done for the
tarball release - so far.

> Unbundling was a pre-requisite of the review request, though, and the
> reviewer found the current solution more acceptable than keeping the
> bundled libev in perl-EV.
> I'm really just trying to fix all this mess here, so what do you think
> would be the better solution?

To follow:

In the case of the FPC not granting a bundling exception, perhaps they
would permit building libev and perl-EV from the same src.rpm. The rationale
for that would be how upstream handles the sources in CVS.

More information about the devel mailing list