[16279] in Kerberos_V5_Development
Re: Project Review: kinit -C
daemon@ATHENA.MIT.EDU (Sam Hartman)
Wed Sep 15 09:49:39 2010
From: Sam Hartman <hartmans@mit.edu>
To: Luke Howard <lukeh@padl.com>
Date: Wed, 15 Sep 2010 09:49:14 -0400
In-Reply-To: <88F50829-AC42-459F-A77A-D9C16389B8C7@padl.com> (Luke Howard's
message of "Wed, 15 Sep 2010 15:20:47 +0200")
Message-ID: <tslzkvjktgl.fsf@live.mit.edu>
MIME-Version: 1.0
Cc: Tom Yu <tlyu@mit.edu>, krbdev@mit.edu,
Nicolas Williams <nicolas.williams@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>>>>> "Luke" == Luke Howard <lukeh@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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
