I'm assuming kerberos5 is something we want in the tree.  If it isn't,
then it isn't.

This is less a completely hashed out proposal than a list of steps that I'm
planning to take to get krb5 integrated..  The descriptions of the steps
should give a pretty good indication of what the finished product should
look like, though..  If you've got questions about this, please ask.

I believe I can have krb5 in the tree, and working decently by 7/14.

--aidan

1) Move all exportable code and headers out of /usr/src/domestic.
	compile_et
	limcom_err
	mk_cmds
	libdyn
   Notes:
	This may give off the wrong impression, like we want to use libcom_err
	for stuff of our own.  This alone may be a good enough reason not to do
	this for some libraries.  Or, maybe we'll actually _want_ people to use
	libcom_err..  I don't know.
2) Merge in my kerb5 changes to login and rlogin.  These build outside of
   domestic (for the most part), but still can require libcom_err.

This can be done now.

3) Import domestic/krb5.
	Perhaps this directory should be domestic/dist/krb5?
	At this stage, nothing uses any source in domestic/krb5..  (The krb5
	changes referred to in step 2) either won't be used by anyone, or
	people will have to provide their own krb5 headers and libraries.)
	Because of this, try to keep the delay between completing this step
	and starting step 5) below brief.
4) Reorganize libtelnet, according to my local model.
	This means the following hierarchy:
	src/lib/libtelnet -- almost all libtelnet sources.
	src/lib/libtelnet/Nocrypt -- libtelnet source that might be overridden
	    by crypto-enabled files.
	src/domestic/lib/libtelnet -- basically contains a reachover Makefile
	src/domestic/krb5/appl/telnet/libtelnet -- contains MIT's libtelnet
	    source

	The src/lib/libtelnet Makefile will look something like
.PATH: {$.CURDIR}/Nocrypt
.include "${.CURDIR}/Makefile.inc"
.include <bsd.lib.mk>

where Makefile.inc contains almost everything in the current libtelnet
Makefile.

	The src/domestic/lib/libtelnet Makefile will look something like
.PATH: {$.CURDIR}/../../../lib/libtelnet
.PATH: {$.CURDIR}/../../krb5/appl/telnet/libtelnet
.include "${.CURDIR}/../../../lib/libtelnet/Makefile.inc"

SRCS += kerberos5.c kerberos.c &c.
.include <bsd.lib.mk>

5) Merge in the rest of the "reachover" parts of domestic/
	This will finally and forever break krb4, except for krb5's
	compatibility code.
6) Make krb4 a package (to help with people upgrading from k4, at least..)
7) Add krb5 support to other existing tools (ftpd, ftp, rsh..) following
   the libtelnet hierarchy.
8) Start work on other local changes, like libprotoauth which I proposed
   to kenh a long time ago.


Stuff that looks troublesome:
GSSRPC.  On Ken Hornstein's advice, I've given up trying to merge libc's
rpc implementation with krb5's gssrpc implementation..  There will be two
RPC libraries installed on the system. (one of which is libc.)
Where this breaks is in header files..  There should be only one set of
header files for both the GSS and the _real_ RPC header files.  I'm
currently just using a bunch of #ifdef GSSAPI blocks in the RPC headers..
I'm not sure how exportable this is, so the source RPC header files have
been moved into domestic/, and we can use unifdef to generate exportable
versions for src/include.  There's probably a better method..