Date: Tue, 26 Sep 1995 11:28:49 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gary@palmer.demon.co.uk (Gary Palmer) Cc: jehamby@lightside.com, hackers@FreeBSD.ORG Subject: Re: ports startup scripts Message-ID: <199509261828.LAA08003@phaeton.artisoft.com> In-Reply-To: <2649.812092182@palmer.demon.co.uk> from "Gary Palmer" at Sep 26, 95 06:09:42 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 1) Who issues these script ID numbers? We cannot let people go > claiming their own at random, as they *WILL* clash (even if we let > them loose on a number domain with 6 significant digits!) Since the scripts have a named "tail" to uniquify them, the question is whether a change in order will cause them to fail. I argue that it would not. If I have a script for a component, the only thing I care about is that my component is started *after* the components which I depend upon. I could care less what other components are started when. > 2) Who is responsible for ensuring that they are in the correct order? > (e.g. something which loads a LKM is run *AFTER* the script to > mount /usr is run). This could potentially be nasty, as the > dependancy tree WILL vary over time (and even from machine to > machine). OK. This is a question of administrative fiat for default components, which have to be figured out (as the current rc files do) by the people who build the default system. People who build components dependent on *default* components are responsible for ordering their components after the ones they depend on. > 3) How will we cope with local alterations (e.g. someone running > locally developed s/w which is only for local use)? Do we leave > large gaps in the numbering to allow for local hacks? There's no real need, but it would be a good idea. It's a good idea, not because of add ons, which only care that they are started after the things on which they depend, but because you might want to split the script at some later date, and in so doing, you will want to push the first part before the current location instead of pushing the second part after the current location. By doing this, you maintain the order without disturbing third party packages. This is why I suggested 3 digits, with the final digit 0, instead of the SVR4 2 digits. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509261828.LAA08003>