From owner-freebsd-hackers  Wed Sep 20 10:24:59 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id KAA20667
          for hackers-outgoing; Wed, 20 Sep 1995 10:24:59 -0700
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA20662
          ; Wed, 20 Sep 1995 10:24:46 -0700
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA01118; Wed, 20 Sep 1995 10:22:25 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199509201722.KAA01118@phaeton.artisoft.com>
Subject: Re: ports startup scripts
To: asami@cs.berkeley.edu (Satoshi Asami)
Date: Wed, 20 Sep 1995 10:22:24 -0700 (MST)
Cc: ports@FreeBSD.ORG, hackers@FreeBSD.ORG
In-Reply-To: <199509201159.EAA04965@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Sep 20, 95 04:59:24 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1370      
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

> As I re-read the archive of the previous discussion, here are the
> proposals and arguments for/against them:
> 
> (1) /etc/rc.d
> 
>  - Ports shouldn't touch anything in the root filesystem
>  + Central location, easy to maintain
>  + Per-machine configuration possible even if /usr/local is NFS shared

[ ... ]

> My opinion is that due to the first reasons on their respective lists,
> options (2) and (3) are infeasible.  I don't have any problem with
> ports touching /etc (that directory is hardly sacred, and is one of
> the things you need to backup during upgrades anyway) but since there
> seems to be a large contingent of people who feel strongly against it,
> I think it's wise to avoid option (1) too.

Actually, I have no problem with ports touching /etc.

The idea of a read-only root implies system templating.

Well, installed software would then be installed on all systems that are
derived from a particular template (via diskless or dataless mount).

The only issue not resolved by this is the idea of that read-only mount
being done from a CDROM (ie: the boot from CD case).  For drop-in
install of package requiring daemons or overall system state, a hybrid
of options (1) and (2) would seem the best bet.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.