Proposed libverto integration plan
ghudson at MIT.EDU
Tue Aug 23 17:07:31 EDT 2011
Here's an outline of what I plan to do to handle the libverto
dependency in 1.10, taking into account the discussion thread:
1. Bundle the libev source in util/k5ev. If util/k5ev is built, it
will install just a shared library named libk5ev and no header.
2. Bundle the core libverto source in util/verto, along with a k5ev
module for it (just a copy of libverto-ev.c adjusted for the libk5ev
symbol names). If util/verto is built, it will install the libverto
shared library, verto.h, and the libverto-k5ev module, but no other
verto modules and no verto-k5ev header.
3. Add a libverto-k5ev module to the bundled libverto which is just a
copy of the libev module adjusted for the libk5ev symbol names.
4. If you configure with --with-system-verto, the bundled verto and
k5ev sources will never be built and the build will require that it
finds an installed verto library and header.
5. If you configure with --without-system-verto, the bundled verto and
k5ev sources will always be built and installed.
6. If you don't specify either, the build will look for an installed
verto and use it if it finds one; if not, it will build the bundled
verto and k5ev.
What I like about this plan:
* krb5 continues to build and work on older systems with no special
* For the verto integration, we won't have to add autoconf grot to
detect glib/libevent/etc. because we won't be installing those
modules. The core verto code will require only minimal autoconf and
* libev is significantly smaller than libevent. Plus, we can do the
build system integration and renaming very easily using libev's
support for embedding.
* The bundled libk5ev won't conflict with an installed (possibly too
old to use) version of libev.
What I'm nervous about:
* In theory, a system could have libverto but no suitable backing
module. We either need to ignore this case as too rare to worry
about (if it does happen, we build a KDC which will fail gracefully
at startup) or detect it at configure time by compiling and running
a program against the system libverto.
* If the bundled libverto is used, it conflicts with a subsequently
installed real libverto but doesn't provide the full set of libverto
modules for applications.
* This is enough work that it presents some minor scheduling issues
since I'm in the middle of the credential selection work. This may
mean we delay the integration of Nathaniel's patch for a couple of
weeks; hopefully this wouldn't be a big deal since he's using git.
More information about the krbdev