[Bug 458785] Review Request: libev - High-performance event loop/event model with lots of features

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=458785





--- Comment #6 from Nicolas Chauvet (kwizart) <kwizart at gmail.com>  2008-09-02 09:07:07 EDT ---
(In reply to comment #4)
> Point 3: fixed by removing event.h because it's, according to upstream, only
> for bw compatibility with libevent -> N/A for me, IMHO.
> 
> """
> On Tue, Aug 12, 2008 at 12:16:40PM -0400, Michal Nowak <mnowak at redhat.com>
> wrote:
> > Do you thing it could be possible to avoid such conflict on upstream
> > basis?
> 
> Unlikely, the "conflict" is by design.
I disagree. AFAIK using a special sub-directory path
> > Giving example, to install event.h, ev.h and ev++.h to /usr/include/libev
> > by default?
> 
> That would break applications that expect to find it as event.h (basically
> all libevent applications).
Thoses can be fixed by choosing which pkgconfig files they will use.
> On Tue, Aug 12, 2008 at 01:06:27PM -0400, Michal Nowak <mnowak at redhat.com>
> wrote:
> > ----- "Matt Tolton" <matt at tolton.com> wrote:
> > > Why not just leave out event.h?  That's just for libevent
> > > compatibility.
> >
> > Thanks, that was my original decision.
> 
> Why not do it like other distributions such as debian, where the common
> header files are installed as alternatives, or optionally?
> 
> event.h is an alternative to the libevent event.h, it's not an unrelated
> header file, it serves the same purpose in both libraries.
> """
event.h from libev and libevent.h are clearly not the same.
if anyone wants to link against libev instead of libevent, the compatibility
layer will not be provided by the Fedora package once event.h is removed.

> (Not yet in mail archive http://lists.schmorp.de/pipermail/libev/)
> 
> Point 4:
> 
> No interest from upstream, probably because when it's in /usr/lib/ no special
> magic is necessary. When it's not upstream -> projects won't use it -> useless
> to have it in Fedora.
>
> What you think?
I think pkgconfig support would solve the co-installation problem along with
giving a accurate value for linking dependant application. (that can pick which
libev.pc/libevent.pc to link with, as a configure option.)
Now if upstream think it is not necessary,then I don't mind. This won't prevent
this package to be good for Fedora. Might be important to check rpmlint output
on installed files for the applications using libev... (to check for
undefined-non-weak-symbol).

But as soon as pkgconfig support would be merged upstream, the dependent apps
can be fixed and patches against dependent applications will have a chance to
be merged. Once done, there is a chance to avoid problems with libev/libevent
-devel been installed on the same system.

So to conclude: I don't want to prevent this package to be approved.
So I just wait to have your answer back.

ps: about your lib.pc , your have picked a bad example. You can see pkgconfig
as an abstraction layer over hardcoded configuration path.
quicklook on this:
http://kwizart.fedorapeople.org/SRPMS/libev-3.43-4.fc8.kwizart.src.rpm

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.