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

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

 



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 #8 from Michal Nowak <mnowak@xxxxxxxxxx>  2008-09-16 04:22:22 EDT ---
(In reply to comment #6)
> I disagree. AFAIK using a special sub-directory path

Agree.

> Thoses can be fixed by choosing which pkgconfig files they will use.

Agree.

> 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.

Agree.

Even though I did diff of both, libev's libevent.h and libevent's libeven.h,
header files, and have seen they are different, I thought it's just old/new
version problem. Didn't even thought it might be evolved one in libev.

> 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.)

Sure.

> Now if upstream think it is not necessary,then I don't mind. This won't prevent
> this package to be good for Fedora. 

That's the point.

I am aware pkg-config it the right solution, but upstream showed no interest in
merging this (thay said it's "by design").

Let's coordinate on this.

I'll ask upstream to provide pkg-config support. If they denies it what to do
next?

A) We remove the libevent.h from libev-devel and install the libev.h (and
friends) to %{_includedir}. The positive on this is that we stay on the same
way upstream is, and that apps linking against libev.h will know where to find
it. The con is that we vaporize possibility to link against libev's libevent.h.


B) We can go our own way, and provide pkg-config support and have libev.h,
libevent.h (and friends) in %{_includedir}/%{name} and then we will fix other
libev dependent packages (it won't be much of them at the moment).


> Might be important to check rpmlint output
> on installed files for the applications using libev... (to check for
> undefined-non-weak-symbol).

I was not hit by this, not never seen it so far, can you please explain
"undefined-non-weak-symbol" to me, or provide some useful link?

> 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

Thanks for the .pc file in private mail, I'll base the "official" one on this,
if we decide we need it/will provide it :-).

-- 
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.

_______________________________________________
Fedora-package-review mailing list
Fedora-package-review@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-package-review

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]