Re: Packaging changes for libev in Rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux