[1905] in Kerberos_V5_Development
binary distributions of krb5 1.0?
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Wed Oct 30 12:44:43 1996
Date: Wed, 30 Oct 1996 12:44:29 -0500
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
I think a lot more people might try krb5 for the first time if a
pre-built binary distribution were available for their platform,
because it would tremendously lower their initial required effort (it
would lower it a lot less than it used to, since the build system is
so much better now, but a lot of people don't know that yet and assume
building krb5 is as hard as it used to be).
What are the reasons not to provide binary distributions? I can think
of a few:
o Disk space on athena-dist. If our binary distributions only
contained gzip'ed tar files containing headers, libraries, and
stripped executables, without .o files and without debugging
information, how much space would it really require? Perhaps not all
that much. Also, perhaps we can arrange for another site to provide
the binary distribution space.
o Liability. We wouldn't want to distribute hacked trojan horse
binaries. But this really isn't a greater risk than distributing
source code, since I bet nobody reads through all of it before
compiling and using it anyway. We could mostly solve this problem by
providing PGP signatures of all the binary distributions. For that
matter, we ought to provide PGP signatures for the source distribution
if we don't already.
o Extra effort at release time. Not really. We should compile every
release we make on every platform we have access to as a regular
matter of release testing. Then, we can just tar up that final test
build tree (or, rather, the result of "make install") as the binary
distribution. Our initial binary distribution set only has to include
those platforms we have access to; we can later accept compiled
distributions from other highly-trusted sources (of which there may be
none) if we wish.
In short, I think this will significantly increase krb5's use (one of
our primary goals) without requiring undo effort or resources, and
therefore is a good idea.
Comments?
Barry
