No mater what architecture a user may be on, the /adm/s/gnutools/gcc/2.91.66-o1/bin/gcc will be the correct one (hopefully).

Each tool will be installed in it's own directory as if it were alone. In GNU-autoconf terminology they will each have there own --prefix. Each tool is to pretend that it is in it's own equivilant of /usr/local/bin/. This will allow us to use graft or stow and combine muiltiple tools in one place for simple use by users.

There are a few extra directorys. The .src directory for any source code, tarballs, pkgfiles, etc. that constitue the rest of the instatlation. Idealy there should be enough material there to diagnose or reinstall that specific version of the tool in case of problems. The .s directory is an extra optional directory for storing S specific files. The files will be used for user <-> admin comunication and posibly a tool regression testing system.

	../bin
          /sbin
	  /lib 
	  /include
	  /man
	  /info
	  (etc.)
	  /.src 
	  /.s	
 

User <-> Maintainer communication:

There is both an implicent and explicit methods for maintainers to communicate with users. The simplest form of communication is the file permissions on the tool directory. If the maintainer wishes to dissalow access to a tool all they will need to do is chmod the tools directory to enable or disable a tool. A more verbose form of communication will hopefully come from the .s directory. Whenever a new tool is installed a general tool description, pointers to responsible people, and documentation should be placed in the .s directory (The exact structure has yet to be defined.). This data will then be fed into a webserver which should allow easy access to that information.

Having the docs close at hand is a win win senario for both users and admins... who are users themselves after all.

Automatic enviroment installation:

In .s there will be shell fragments in the sys-V startup script style. If any application needs enviroment variables set, that can be done automaticly for the users.

Everyone gets there own /usr/local

By using graft, stow, or scripts users quickly and easily build there own sets of tools. Nolonger will paths have to be 20 elemets long and traverse thousands of commands, they can be only what is required for the job, and always the correct version.

An rough example of a graft based script for building a /usr/local/ equivilant.

#!/bin/sh

echo ""
version="1.0.4"

echo Version $version

targetdir="$HOME/ag"

echo targetdir $targetdir

echo ""
/bin/find $targetdir | wc -l
/bin/du -sk $targetdir
umask 022
echo "rm ing old $targetdir"
/bin/rm -rf $targetdir
echo "mking new $targetdir"
/bin/mkdir $targetdir

echo "grafting $targetdir"


/adm/s/util/graft/2.3/bin/graft -i -t $targetdir \
	/adm/s/data/stats/r/1.2.3 \
	/adm/s/util/graft/2.3 \
        /adm/s/data/vis/gnuplot/3.7.1_gd \
	/adm/s/dev/bison/1.28 \
	/adm/s/dev/flex/2.5.4a \
        /adm/s/dev/gcc-fake-cc/1 \
        /adm/s/dev/gcc/2.95.3  \
        /adm/s/dev/binutils/2.11 \
        /adm/s/dev/gmake/3.79.1  \
        /adm/s/dev/perl/5.005_03 



echo "building whatis database"
/usr/bin/catman -w -M $targetdir/man
	

echo ""
/bin/find $targetdir | wc -l
/bin/du -sk $targetdir

But what good does it do?

• Let's start with an example. /usr/local/bin/perl, the nemissis of any sysadmin. Perl is curently under active development, and has hundreds of optional modules that users may, or may not be using. If every user in your site is coding there perlscripts to /usr/local/bin/perl, whenever you need to update or upgrade perl a regression should be run on each and every one of thouse scripts. If the regressions are not done you'll run there risk of breaking production code. Every new revision of perl seems to add things to the -w flags list of nono's. If a perl script is burried three layers deep in a pipeline and it studdenly starts spewing the wroung output, you have a problem.

  And if you thought the migration from perl 4 to perl 5 was tough, the migration from 5 to 6 will be hell.

• Another problem with perl is exactly thouse hundreds of packages. You will finds times when different user communitys have different conflicting requiremnets that can not be resolved due to version mismatches or collissions.

  S can help to solve this. If every project, group and user buld there own /usr/local/bin equivilants out of simlinks, they can always, simply and easily modify the version of perl they are linking to without rocking the version boat for over users. Simple and clean.

• Problem that often crops up is user tool mis-match. If two cooperating users accidentaly get too using the wroung tool versions horrible Heisenbugs can start croping up do to slightly different bug sets, or linking against two different sets of .h files, or the equivilant.

  S can simply solve this problem by constructing a shared tool directory for your group.

• Engeneers are often called on to work on multiple projects at once. Normaly these projects do not share the exact same tool revisions. S can help simplify the process of switching from one working set of tools to another. All a user would need to do is run a single command to swap there current enviroment for different set of custom built paths and enviroment variables.

Future direction

• Editing graft scripts is all well and good, but a nice curses or tk interface would be helpfull for toolset construction.
• A ports like system for automaticly compiling/installing the majority of tools would be very simplifying.

Footnotes:

1. NFS, the Network File System. It sucks, but so does gravit, and gravity is damn usefull too.