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
