[1016] in Moira
sipb-athena moira clients
daemon@ATHENA.MIT.EDU (Dan Winship)
Sun Oct 20 18:40:38 1996
Date: Sun, 20 Oct 1996 18:40:25 -0400
From: danw@MIT.EDU (Dan Winship)
To: moiradev@MIT.EDU
The moira clients on the (Athena) syspacks point to the copies in the
moira locker so we can update them outside of the release cycle, which
is a good thing (ie, making it harder to shoot yourself in the foot
with blanche).
The ones in the sipb-athena linux/netbsd syspacks are not set up like
this. They are also built from a source tree in the sipb cell instead
of the tree in moiradev. This means that any changes we make have to
be copied over and incorporated into that source tree by hand, and
that the binaries aren't updated in any useful time frame. This means
that linux and netbsd users on campus don't get the moira client
bugfixes that we think are important enough to have gone out of our
way to take moira out of the release cycle for.
There _have_ been problems with this. One example is the 8-character
limit on get_user_account_by_login, which was violated by an older
version of the moira client, which hosed the server. This bug still
exists in the linux/netbsd moira, so they were continuing to hose the
server until we fixed it on that side. The netbsd/linux syspacks also
don't have the improved blanche yet.
As more and more users start using linux and netbsd, this could become
more and more of a problem. Jonathon and I think it makes sense for us
to maintain linux and netbsd binaries in the moira locker, with the
sipb-athena syspacks pointing to them. For now, we would continue to
build them out of the sipb-athena source tree. Over IAP, I'm planning
to `autoconfiscate' the moira source tree and incorporate the changes
from the sipb-athena to produce a public distribution of Moira 4.
After that, we would be able to build all of the binaries from one
tree.
I've talked to ghudson (SIPB head netbsd guy) and warlord (SIPB head
linux guy), and they both say this sounds fine to them if we want to
do it.
-- Dan
