From owner-freebsd-ports Thu Sep 21 09:46:44 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA19083 for ports-outgoing; Thu, 21 Sep 1995 09:46:44 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA19067 ; Thu, 21 Sep 1995 09:46:37 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id JAA02905; Thu, 21 Sep 1995 09:45:21 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA22389; Thu, 21 Sep 1995 09:50:45 -0700 Date: Thu, 21 Sep 1995 09:50:45 -0700 Message-Id: <9509211650.AA22389@asimov.volant.org> To: chuckr@eng.umd.edu, gryphon@healer.com, kelly@fsl.noaa.gov Subject: Re: ports startup scripts Cc: asami@cs.berkeley.edu, hackers@freebsd.org, julian@ref.tfs.com, ports@freebsd.org, terry@lambert.org X-Sun-Charset: US-ASCII Sender: owner-ports@freebsd.org Precedence: bulk |> When are you going to start a daemon in more than one place? |> Or set a global environment variable, then change it later? |> |> Define it as "Run Level N" includes all "Run Level 0..N-1". Simple. If it really were that simple, why didn't SVr4 do it that way? |> > the same sort of problem ourselves. (And, again, I urge consistancy |> > with existing implementations. There's no point in being the only |> > ones to use 'rc.?' if everyone else is using 'rc?.d'.) |> |> We are not System V. If we want to be System V stop calling ourselves |> FreeBSD and become FreeUnix (FreeNix anyone? :-) I'm not suggesting that we become System V. But if they have a better solution to one of our problems, why not adopt it? I have no problem with differences that provide some significant technical advantage. But differences just because "we aren't System V" only hurt us. We don't want people refusing to run FreeBSD because it is too different from the other unixes, (without significant advantage) do we? |> Seriously. If we want to throw away how /etc/rc works (and it does |> work), then only take from other camps what we need. I have yet |> to see a standard out (ie. all parts work identically) there on the |> 8-10 unix flavors that I work with. So which one are you going to clone? We have two reasonable choices: 1. Whichever one we feel is technically superior. 2. The one with the biggest market presence (Solaris2). |> > cron.d |> |> Crontab entries already exist in /var/cron/tabs, except for root's entry |> which is in /etc. You could easily move it to /var/cron/tabs as well. Solaris keeps the crontab entries in /var/spool/cron/crontabs, with at job entries in /var/spool/cron/atjobs. /etc/cron only contains the administrative scripts (logchecker), access control files (at.deny, cron.deny), etc. |> > mail |> > Mail.rc, aliases{,.dir,.pag}, mailx.rc, main.cf, sendmail.cf, |> > sendmail.hf, subsidiary.cf |> |> OK, or can be in /etc/inet. Could be, but I kind of like the separate dir for mail. |> > skel |> > Default user rc files. (.profile, local.cshrc, |> > local.login, local.profile) |> |> I put all the stuff normally in /usr/share/skel in /etc/skel. |> If you want all the default stuff ("csh.cshrc" as well as "dot.cshrc") |> that makes sense to me. The current /usr/share/skel is a fine location. |> > default |> > Default versions of some control files: cron, fs, init, |> > login, passwd, su, tar, utmpd |> |> Why bother? We are shipping a live file-system CD anyway. |> If they download it and want the default stuff, keep it somewhere else. I tend to agree. But I was on the SunSoft WOS (Wad Of S*) team for a while, and I know how tight they are on space usage. I can't help but suspect that there is some less obvious reason for having these files. (I'm certainly willing to forego them until we find it though.) |> > opt |> |> Same as with shared libs and other executables: please no. Even in Solaris /etc/opt is depreciated in favor of /opt. The FreeBSD convention is to install everything into /usr/local. The separate-subdir-per-vendor (or major package cluster) has some adantages for installation, update, and multiple version support; but makes for huge PATHs and confuses some users. |> > named |> > DNS server control files |> |> OK, it can be separate or combined with /etc/inet Keep it where it is (/etc/namedb). All of the books on DNS and BIND expect it to be there. (I would class moving it into /etc/inet as a gratuitous difference.) |> Let's not go overboard and try and stick everything in it's own |> little nook and cranny. |> |> One directory for network related config files (that will change |> from system to system). One directory each for major subsystems |> (UUCP, PPP, NEWS). I define major subsystems as ones that have |> more than a half dozen files to keep track of just for it. Agreed. (Although I wouldn't necessarily make half a dozen a hard limit. After all named only has five.) -Pat