*BSD News Article 5312


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Patch 00007
Message-ID: <1992Sep20.091406.10641@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <sxjcb-190992175158@sxjcb.uacn.alaska.edu>
Date: Sun, 20 Sep 92 09:14:06 GMT
Lines: 60

In article <sxjcb-190992175158@sxjcb.uacn.alaska.edu> sxjcb@orca.alaska.edu (Jay C. Beavers) writes:
>
>When I use the patch installer to try to install patch00007, I get an error
>installing the patch.  I've looked at patch00007 and part patch.3 seems to
>be trying to access a file in the /usr/src/sys.386bsd/sys directory.  As I
>had no such directory, this is a bit of a problem!  I deleted my /usr/src
>directories and reinstalled the src01 files using:
>
># sh
># (for i in /.../src01.*; do
># cat $i
># done
># ) | uncompress | cpio -iadm
>
>From / where the src01.* files were nfs mounted from wuarchive (and the
>directory to the files was specified correctly where /.../ is).  Again, no
>/usr/src/sys.386bsd/sys directory existed.  Is this a problem with the
>patch, the files on wuarchive, or my method of extracting them?

This is [apparently] a problem with your installation.  This directory should
contain the header files you will see if you "cd /usr/include/sys; ls".

In a standard (default) installatiom, /sys is a symbolic link to
/usr/src/sys.386bsd and /usr/include/sys is a symbolic link to /sys/sys.

Since the files being patched were modified, I used the real paths to get to
them so that the targets would never be "missing".  This is an assumption of
a larger disk installation, but should not cause you trouble if you have
correctly installed the sources, since these symbolic links should exist.
This *does* give preference to local installation of system sources and NFS
mounting of your own developement work if you have a medium-sized disk,
rather than the other way around, but as an intentional configuration
tradeoff, it isn't a bad one (you are unlikely to be able to compile a
remotely mounted kernel without the patches installed anyway).

I have been reconsidering, on the basis of multiple concurrent source trees,
the use of absolute paths rather than the symbolic link equivalents.  It
seems to me that, perhaps, a path using a symbolic link is preferrable.  If
this can be uniformly implemented (such that "/src" is a symbolic link to
"/usr/src", or "/usr/src" is a symbolic link to ???), I may backtrack.
Currently, this is only applicable to kernel code via the /sys symbolic link,
and I felt that this was insufficiently flexible in terms of other sources
and therefore justification of the "absolute path" approach.

Of course, there is nothing preventing /usr/src/sys.386bsd from being a
symbolic link to an NFS mounted/hard mounted source partition elsewhere, so
this may not be a real problem.
 

					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------