[6372] in SIPB bug reports
Re: The Sipb locker contains more than just executables...
daemon@ATHENA.MIT.EDU (Salvatore Valente)
Thu Jun 5 02:24:06 1997
Date: Thu, 5 Jun 1997 02:23:49 -0400
To: mhpower@MIT.EDU
Cc: bug-sipb@MIT.EDU, bug-sipb-new@MIT.EDU
From: Salvatore Valente <svalente@MIT.EDU>
Matt wrote:
Was big-sipb@MIT.EDU just a typo for bug-sipb@MIT.EDU?
Yes.
>The sipb-new locker is more-or-less ready to go, that is, it contains
>99% of the necessary software.
I'm not sure I understand how you came up with the figure of 99%.
I made it up. It was a complete, outright lie.
Of the programs you listed as missing, I've installed:
fingerprint (cksum, fptocksum, fptosnefru, fptomd5, md5, snefru),
fwhois, hcal, hdate, rn, rrn, xcal, mcread, mcvert, and zsh.
The other programs you listed are:
* cda - part of xmcd. It's in the audio and consult lockers.
* fortune - I'll install this, but maybe we should look into finding a
new fortune database... Everyone must have heard all of our current
fortunes by now. :-)
* macps, prepfix - I'm fairly certain this no longer serves any purpose.
* moonphase - Seems to be part of a package for which I can't find most
of the source. Never built for SGI. I consider it desupported.
* nawm - it's in the nawm locker. I'll symlink the binaries from the
nawm locker to the sipb locker if the nawm maintainers think it's a
good idea.
* netstats - I have no idea what this is, but it's not executable.
* nvi, vile, xvile - Again, never built for SGI. Since vim is in the
sipb-new locker, I consider these unsupported.
* pps, slide - I haven't been able to get this to work on most platforms.
It has never worked for SGI. I consider it desupported.
* prtgif - "man prtgif" explains why there is no longer a prtgif executable.
* rcextract, rcindex, rcnroff, rcshow, rctypeset - somehow, a cookbook
sounds like an odd service for Sipb to provide...
Still, I suppose it should be installed.
* type - Is this the quality of software we want to provide?
Also, there are some programs installed in sipb-new for the sun4
platform but not installed there for the the decmips platform:
I've installed all of these for decmips.
There are also lots of programs that exist in the sipb locker for
the decmips platform but don't exist there for the sun4 platform.
arc beav hebcal joe lcal memo omer ship sm splot tek2ps utree
vcal vmail zoo
I'm not thrilled with the idea of installing a lot of these in the
sipb-new locker. I'd like to replace them with a shell script that
says that they've been desupported and that if you want to run them,
send mail to bug-sipb and we'll probably re-support it or try to
provide an alternative.
For the rt and vax platforms, the only program in sipb-new is
archie...
Yeah, the loss of the rt and vax platforms is the major disadvantage
of rebuilding the sipb locker. (This begs the question: What is the
advantage of rebuilding the sipb locker? I don't feel like trying to
answer that right now.)
We will keep the old sipb locker (at least vaxbin, rtbin, and lib) in
/afs/sipb/project/sipb-old. On Sipb's RT, we can probably modify the
local nameserver so that "hesinfo sipb filsys" returns
/afs/sipb/project/sipb-old. We can make a "sipb-old" filsys pointer
and try to "advertise" this for other people with Vaxen and RTs. I
realize that this is a lousy solution to the problem.
Also, there's no arch/sun4m_412 directory.
Fixed.
Is it ok to copy any binaries from the sipb locker into sipb-new?
It's not a big deal, provided there are no hardcoded paths in the
executable that fail with the new layout. Of course, I'd like to keep
the sipb locker source tree in sync with the executables as much as
possible.
The top level of sipb-new doesn't contain the directory sun4bin.
I'm reluctant to create the sun4bin symlink, although I can't give a
real good reason why. Anyone else want to try?
This seems to be unhelpful to users who follow either the olh
(http://web.mit.edu/olh/Dotfiles/Dotfiles.html#making_new)
Yeah, but that page begins with "IMPORTANT NOTE: The information in
this document is OUT OF DATE..."
or olc (http://consult.mit.edu/.../other_sipb.html)
Hopefully that will be updated.
or who did what we told them on the first page of Inessential Athena.
Kretch updated that section in January 96. However, he says his
changes aren't finished yet.
Also, Inessential AFS (page 13) implies that paths starting with
/mit/sipb/@sys are ok, and some users have this in their dotfiles.
Yuck. That entire section of iAFS is in serious need of rewriting.
Anyway, people who put /mit/sipb/@sys in their path in their path will
notice that they can't run sipb locker programs anymore and hopefully
will figure out why and be able to fix it. It must be a small group
of people and I don't think the top level of the sipb locker should be
cluttered to accommodate them.
I hope I've addressed most of your concerns.
-Sal.
