Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Feb 2002 08:53:15 -0500
From:      Ken Stailey <kstailey@surfbest.net>
To:        Alan Eldridge <alane@geeksrus.net>
Cc:        "."@babolo.ru, ports@FreeBSD.ORG, klh@panix.com
Subject:   Re: [ade@FreeBSD.org: suggests installing in a USER's HOME dir]
Message-ID:  <3C6E644B.3080102@surfbest.net>
References:  <20020216034549.GA51544@wwweasel.geeksrus.net> <200202160623.JAA27217@aaz.links.ru> <20020216070656.GA87963@wwweasel.geeksrus.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Alan Eldridge wrote:

>On Sat, Feb 16, 2002 at 09:23:57AM +0300, "."@babolo.ru wrote:
>
>>Alan Eldridge writes:
>>
>>>----- Forwarded message from Ade Lovett <ade@FreeBSD.org> -----
>>>On 02/15/02 21:21, "Alan Eldridge" <alane@geeksrus.net> wrote:
>>>
>>>>But nobody ever did chime in with an idea of where the best place to put
>>>>a 200-400MB *writable* file, installed by a port, is. And that, of course,
>>>>was the whole point in cc'ing portmgr. So, any thoughts on that?
>>>>
>>>Bottom line is, there's just no reliable way to pick a place that will fit
>>>the requirements of (1) unique to local machine (2) big enough (3) writable.
>>>
>>I think use of environment variable is good enough.
>>${EMULATOR_SPACE} for example (directory for all emulator's disk images)
>>administrator can set it in login.conf for everybody
>>or for some classes of users, user can set EMULATOR_SPACE for
>>himself, and no user install if script does not detect
>>this variable.
>>
>
>Ken, does it get directories from env as well as .ini file?
>
>If it doesn't, then this would entail some invasive software mods that
>I think are beyond the scope of a port, unless the original author was
>willing to incoroporate them into the base distribution.
>
I don't get this at all. Are you saying that it's OK to tell a user to 
modify an env var but not an .ini file?

Seems like all I hear about are limitations I don't understand the 
reason for and over-engineering like layers of scripts to position files 
when there are already ways to tell the Makefiles what to do.

The details as pertain to the port.  From the top down:

its(1) command.  A script.  Tells where to pick up the emulator binary 
and what directory the .ini file and emulator bootstrap non-native 
binaries are in.  Also does lockf(1) on the filesystem image.  The its 
script is told where to find these things from the "make install" 
procedure.  The script is located in $PREFIX/bin.

.ini file.  A KLH10 configuration file.  Controls where the filesystem 
image is and the emulator IP address. Again "make install" can patch the 
.ini file to control these parameters.  Located in 
$PREFIX/share/klh10-ks-its.

Emulator bootstrap files.  These are not native binaries but ITS ones 
that are in the native filesystem not the image filesystem.  Located in 
$PREFIX/share/klh10-ks-its .  Must be in the same directory as the .ini 
file.

Emulator binary (and data conversion support native binaries.)  Located 
in $PREFIX/bin.

Filesystem image.  Defaults to $PREFIX/share/klh10-ks-its.  Controlled 
by "make install IMAGE_HOME=/foo"

Documentation.  Located in $PREFIX/share/doc/klh10-ks-its

Usage:

# cd /usr/ports/its
# make install IMAGE_HOME=/home/its
[does KLH10 port install automatically if not already in place]
[does ITS filesystem extact to $WRKSRC and frobs its.sh into the its 
script ]
===>  Installing for its-a11110
===>   its-a11110 depends on file: /usr/local/bin/kn10-ks - found
***  Please read /usr/local/share/doc/klh10-ks-its/README.FIRST
===>   Generating temporary packing list
===>   Registering installation for its-a11110
(read docs, install firewall)
# its                (as root the first time to creat APR.TIMEBASE and 
then shutdown ITS)
#
from this point on
$ its

A second attempt to run the its(1) script will produce an error due to 
lockf(1) of the emulator image.

If you want to have multiple copies of the emulator binary set $PREFIX 
to something else when you "make install".

Plain and simple.  Any problems?

Thanks,
Ken





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C6E644B.3080102>