[381] in NetBSD-Development

home help back first fref pref prev next nref lref last post

Re: Problems with /afs/sipb/project/sipb-athena

daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jan 13 09:16:03 1995

To: jhawk@MIT.EDU
Cc: netbsd-dev@MIT.EDU, svalente@MIT.EDU
In-Reply-To: Your message of "Fri, 13 Jan 1995 05:38:44 EST."
             <9501131038.AA24911@binkley.MIT.EDU> 
Date: Fri, 13 Jan 1995 09:16:04 -0500
From: Greg Hudson <ghudson@MIT.EDU>


> *	mh		mhconfig fails

Someone left some cruft in /afs/sipb/project/sipb-athena/mh, including
a Linux version of conf/mhconfig.o and conf/mhconfig.  I removed them,
and it builds fine.

> *	zephyr		Imake template errors

This is because XFree86 3.1's xmkmf is a little bit different from
everyone else's.  I changed the build directions to use imake
directly.

I'm sure the other errors are as minor, but I don't want to spend a
lot of time checking them out since I wasn't the person to put
together those source trees.  I might check on kerberos.

(Actually, I am responsible for telnet.  Does the installed
/usr/athena/bin/telnet exhibit the same problem as the Athena telnet?
If not, then something is odd, since I fairly recently built and
installed telnet from the sipb-athena source tree.)

> 	Where do imake and xmkmf come from? Is the user expected
> 	to build them first? ?? How do Yoav's changes affect this?

imake comes from the system's X installation, which is perhaps a bad
idea, but hasn't caused is trouble yet.  We no longer rely on xmkmf,
so that's not a big issue.

> It also seems disturbing that the original location of these source
> files is not documented (dev cell, <foo>dev locker, whatever), nor
> are context diffs included. This means that when the next version
> of, say, hesiod, comes out, it will not be clear just what changes
> were necessary to support it.

The theory (as introduced by Sal) is that you copy over the source
directory from the Athena release (except for kerberos, which came
from the Cygnus source tree) and clear out all the RCS directories.
Then, when you want to update the source, you can determine the
relatively small number of changes that were made by looking for RCS
files.

A couple of packages probably came from lockers and not an Athena
release, but that shouldn't affect the theory, since it's just a
version difference.

Some packages do not have their RCS directories cleaned out, because I
wasn't aware of this practice (and hadn't thought up the idea) during
all of the time I was doing work on the port.  It would be relatively
easy to write a script that looks for the last modifier (using rlog)
of all files in the source tree, and recognize sipb-athena developers
there.  We could then clear out the other files to make it relatively
easy to determine what changes were necessary.  (This wouldn't work
for the zephyr source tree, since I regularly modify the Athena zephyr
sources, but our zephyr sources have the RCS files cleared.)


home help back first fref pref prev next nref lref last post