Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!decwrl!mcnc!uvaarpa!mmdf
From: marc@athena.mit.edu (Marc Horowitz)
Newsgroups: comp.lang.perl
Subject: Re: 4.0 beta available
Message-ID: <1991Feb25.034137.10651@uvaarpa.Virginia.EDU>
Date: 25 Feb 91 03:41:37 GMT
Sender: mmdf@uvaarpa.Virginia.EDU (Uvaarpa Mail System)
Reply-To: marc@mit.edu
Organization: The Internet
Lines: 25

|> We're weird because we run AFS.

So are we.  This message sounds really familiar :-)

The workaround I devised for this is certainly a crock, but it does
work.  (I'm about to plunge into AFS details.  Skip the rest of the
paragraph if you don't care.)  In our root.afs volume, .root.afs is a
read-write mountpoint for the root.afs volume.  Therefore,
/afs/.root.afs/athena is the same as /afs/.athena.  The trick is that
given a machine I can hack on, when it's time to install perl, I can
change the cacheinfo file to mount AFS on /afs.ro, and make /afs a
symlink to /afs.ro/.root.afs.  Then, all installs to
/afs/athena/contrib/perl indirect to the r/w volume, and normal users
get the backup volume once it's been released.

It seems that the ``right'' solution is to have two configure
variables, one for where the binaries/scripts/libraries should be
installed, and one for where they should be read from.  It should be
possible to make the defaults clever enough that they are correct on
most normal systems.

I'd be glad to try to do this, since I have afs, or I can arrange a
guest account here for Larry.

		Marc