[3022] in SIPB bug reports
Re: gnuserv not installed properly in sipbsrc
daemon@ATHENA.MIT.EDU (raeburn@Athena.MIT.EDU)
Thu Jul 9 19:24:35 1992
Date: Thu, 9 Jul 92 19:23:52 -0400
From: raeburn@Athena.MIT.EDU
To: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
Cc: ckclark@MIT.EDU, bug-sipb@Athena.MIT.EDU
In-Reply-To: <9207090339.AA21942@pit-manager.MIT.EDU> (jik@pit-manager.MIT.EDU)
Date: Wed, 8 Jul 92 23:39:12 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
Seriously, yes, sipbsrc would get pretty big, but it already *is*
pretty big, and we *have* the disk space. Disk space is a lot cheaper
than having to tell users who send in bug reports saying, "Program <x>
dumped core, the core file is in file <y>," and not being able to do
anything about it because we don't have unstripped binaries and
building the program again results in a binary that doesn't match the
core file.
This *does* happen. People in the SIPB tend to develop programs, not
just install them. And even when we install something from the net,
if it coredumps we tend to try to track down the problem before send a
bug report to the real maintainer. We can't do that if there aren't
object files.
If people are changing the sources without reinstalling, you're going
to lose anyways. If they rebuild a version for (say) the RT but don't
install it, you have an executable-with-symtab that doesn't match
what's installed, so it's useless for debugging; if they don't rebuild
it, you have .o files that don't match the sources, so you should
rebuild to see if the bug is still there. (And I'm blindly assuming
you don't change compilers or compiler options....)
Why not install binaries with the symbol tables, and discard the build
trees for things that aren't frequently having work (development or
debugging) done on them? That would probably result in a reduction of
overall disk usage, even though it would mean expanding project.sipb.
