----- "Marc Lehmann" <[EMAIL PROTECTED]> wrote:

> On Tue, Aug 12, 2008 at 12:16:40PM -0400, Michal Nowak
> <[EMAIL PROTECTED]> wrote:
> > Do you thing it could be possible to avoid such conflict on upstream
> 
> > basis?
> 
> Unlikely, the "conflict" is by design.

But this prevents to have libev's and libevent's libevent.h both
in system. And those versions of libevent.h are not the same.

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

Now we intend to leave original event.h in in same place where is 
now and move libev's libevent.h to /usr/include/libev/ and to fix
apps relying on libev and looking for ev.h and friends in /usr/include
by pkg-config (attached).


> On Tue, Aug 12, 2008 at 01:06:27PM -0400, Michal Nowak
> <[EMAIL PROTECTED]> wrote:
> > ----- "Matt Tolton" <[EMAIL PROTECTED]> 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.
> 


Not sure what you mean. Now we install header files only when need -- 
on demand in devel package, so the use of libev itself as a library is
in now way prevented.

Well, packaging libevent.h in a separate sub-package and make it 
conflicting with libevent-devel is not necessary, when we move
libev to /usr/include/libev and use pkg-config to "find" it.

Michal

Attachment: libev.pc.in
Description: Binary data

_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

Reply via email to