[17111] in Kerberos_V5_Development
Re: Proposed libverto integration plan
daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Wed Aug 24 09:19:50 2011
From: Nathaniel McCallum <npmccallum@redhat.com>
To: ghudson@mit.edu
Date: Wed, 24 Aug 2011 09:19:42 -0400
In-Reply-To: <201108232107.p7NL7Vde012737@outgoing.mit.edu>
Message-ID: <1314191984.2440.5.camel@localhost>
Mime-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, 2011-08-23 at 17:07 -0400, ghudson@MIT.EDU wrote:
> * 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.
My patch already detects this case and fails gracefully with a log
message. I assume it will be only packagers that will build with a
system libverto. In the libverto RPM I've built, there is a
libverto-modules-base virtual dependency which will ensure the "base"
set of features: io, timeout and signals. All the packager (I'm pretty
sure it will be me for Fedora) has to do is make sure that the kdc
depends on libverto-modules-base.
The other possibility is to depend on libev directly, by linking against
libverto-libev.so and calling verto_default_libev() (in verto-libev.h).
In this case most distros will simply handle the dependency like any
other linked library. I prefer the first method however...
Nathaniel
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
