Project Review: kinit -C

[Sam Hartman]

>>>>> "Luke" == Luke Howard <lukeh at padl.com> writes:

    Luke> Yeah, if we're doing this way I'd prefer to build kinit and
    Luke> kinit.local. That's consistent with kadmin.  -- Luke

Right.  It's kadmin.local that makes me want to avoid doing something
similar.  We certainly can do that if needed. However as a packager I've
found kadmin vs kadmin.local to be a significantly worse experience than
adding a couple of extra libraries as dependencies to the package
containing kinit.

Now, that's my personal analysis.  If someone looks at the situation and
concludes that these sorts of dependencies would be a problem for them,
I think we should solve that.  So far, as I've been reading the
discussions, we've had a couple of people say that it might be a
problem, and a couple of others describe the issue and note that it is a
change.

The costs I see to kinit.local are:

* user confusion--two binaries, when do you use each of them
* man page confusion
* build system complexity--having executables that share most of the
 same code

If we do decide to build binaries I'd probably recommend that kinit have
full functionality and also build kinit.non-kdc or build kinit.full and
kinit.non-kdc and create a symlink.

The packaging issue is the only one I've identified; if there are other
issues I'd definitely like to consider them.