DragonFly submit List (threaded) for 2008-07
DragonFly BSD
DragonFly submit List (threaded) for 2008-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: libevent upgrade from 1.3e to 1.4.5-stable

From: "Samuel J. Greear" <dragonflybsd@xxxxxxxxxxxx>
Date: Fri, 4 Jul 2008 14:32:30 -0700

"Antonio Huete Jimenez" <tuxillo@quantumachine.net> wrote in message 486bf4f3$0$850$415eb37d@crater_reader.dragonflybsd.org">news:486bf4f3$0$850$415eb37d@crater_reader.dragonflybsd.org...

Here's a working patch for upgrading libevent. It compiles just fine and I'm currently using in one of my DFBSD machines.


Bug fixes can be found in:


I don't have the oportunity of checking with bluetooth because I don't have any device, so if someone has devices and time, please check.

About ABI changes, there are some functions that have been removed, and some parameters slightly changed:

. ..

Samuel Greear (sjg), I invite you to give your opinion here just like at IRC ;-)

-- * Please, consider your environment before printing this email Cheers tuxillo at EFNet in #dragonflybsd

Considering the primary rationale for importing libevent (to my knowledge) is to
support libbluetooth, and given that it is readily available via pkgsrc and is
known to have an unstable ABI. Wouldn't it make the most sense (short of
rewriting libbluetooth not to use libevent) to either move libevent into a
subdirectory of libbluetooth and link it directly into libbluetooth, potentially
dropping the manpages. Or, expose it as dflibevent or similar noting prominently
that it is generally intended for base system use and third party binary
applications should not expect it to maintain a stable ABI? My preference would
be toward the former more than the latter, at least until some other consumer of
libevent hits base. Either way it would pretty much eliminate any ABI breakage
concerns which fly in the face of a preference to upgrade the library upon every
new release. I would think the ideal would be for third party applications to
prefer pkgsrc for something like this. ABI breakage is probably no big deal at
current but could get bumpy down the road (I'm not sure how this would factor
into process checkpointing in the case of restoring a libevent-dependant process
elsewhere, where libevent exposes a different binary interface). In any case,
maintenance and updates of select and poll support for libevent can likely be
pulled from the tree.

I can prepare a patch if there is some kind of consensus.


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