(At this point, I think this discussion should go to tech-install.
Everybody agrees?)

>
>> 	2. Scripts in /usr/local/bin, which invoque the binaries,
>> perhaps setting up some environment first. For man pages, modifications
>> to man.conf. This is more difficult to automate.
>
>Hu? Why fiddle with man.conf if you've links from the packages to
>/usr/local/man? It's enough to just include /usr/local/man in MANPATH, works
>fine not only under NetBSD. :)

	I meant *if you don't want to have links from /usr/local/man*.
Anyway, I was just wondering, because I've found that it's
hard to keep in sync man.conf files in lots of machines...
The links thing is a bit dirtier, but works better, I guess.

...

>> /usr/local/test/foo-2.3: Where packages are built and tested.
>> /usr/local/distrib/foo-2.3: Where gzipped tared packages (original
>>   and patched distributions) are available. Useful for a ftp server.
>
>Hm... true, but you'll have to mount more disks on /usr/local/test and prolly
>/usr/local/distrib ;-)
>
>The idea of /usr/local/install sounds ok, as it doesn't fill /usr/local up with
>the packages but hides them in a single dir. :) I'd like to use another name,
>though, as 'install' doesn't really reflect what's in there. How about
>/usr/local/pkgs?

	At this point I'm beggining to see that it's going to be very
hard to find a name which everybody agrees on. Probably the
best thing should be an schema that let's people choose their own
name... Maybe that can be done wrapping the calls to binaries
in shell scripts that set up the proper environment, when needed.
I remember reading something about this in ;login some years ago,
anybody saw it?

>> 	Currently we are thinking about using /usr/local/install/foo-2.3/doc
>> or /mix/share/foo-2.3/doc for that, maybe with proper links
>> (like the one I mentioned for man pages) from /mix/share/doc.
>
>/mix?! :-> Now as there is /usr/share, i'd rather place it somewhere there...
>shall we create a subdir under doc (doc/pkgs), or something like
>/usr/share/pkgs? (in analogy to /usr/local/pkgs ;-)
>

	When we install a new version of the OS (e.g., from NetBSD-1.0
to NetBSD-1.1), I don't want to have to merge the new /usr/share
with my local additions. In general, I want the O.S. in one place,
and all the packages (aditions to the system) in other. Now, when
we upgrade (or install a new machine), just install the OS, make a couple
of links, and everithing is up and ready.

	About /mix, that's the root of everything that could be useful
to more than one machine. Our directory strucutre is a bit complicated,
because tries to cope with different archs and different OSs and
easy of installation, and easy of upgrade, etc.

	For instance, every machine sees the binarires for itself under
/usr/local, but just because that's a link (o an amd mount)
of /mix/arch (for instance, we have /mix/netbsd-i386-1.1).
Everybody can see everithing under /mix, but machines see "their part
of the game" under /usr/local.

>I guess package-maintainance was mentioned by Rob Healey(sp?) or so, and i
>agree that we would benefit from that concept. No more having to fiddle with
>/etc/rc.local for adding some package.
>
>If this concept should not be realized soon, we could help ourselves with
>something like the following in /etc/rc.local:
>
>for i in /usr/local/pkgs/*/install/bootscript
>do
>	$i start
>done

	I agree with that idea. Or maybe just a call to
/usr/local/etc/rc, wich will be itself a list of calls to
/usr/local/install/pkg_name/etc/rc. That list can be just
calling /usr/local/install/*/rc, or forcing maually some order,
or even automatically built by some tool from a dependency list.

		Jesus.


--
Jesus M. Gonzalez Barahona         | addr.:  c/ Butarque, 15
Grupo de Sistemas y Comunicaciones |         28911 Leganes, Spain
Departamento de Informatica        | tel: +34 1 624 94 58
Universidad Carlos III de Madrid   | fax: +34 1 624 94 30
e-mail: jgb@gsyc.inf.uc3m.es       | www: http://ordago.gsyc.inf.uc3m.es/~jgb