Date: Tue, 26 Sep 1995 09:00:09 -0700 From: patl@asimov.volant.org To: gryphon@healer.com, hackers@FreeBSD.ORG, peter@taronga.com Subject: Re: ports startup scripts Message-ID: <9509261600.AA00748@asimov.volant.org>
next in thread | raw e-mail | index | archive | help
|> > |> 2 is easy. The GUI controls the file writing in all cases |> |> > If you think this would be a popular decision, talk to anyone who |> > has fought with Solaris2's AdminTool over serial port or printer setup. |> |> I'm not talking about hardware configuration. I am talking about |> what to run when in terms of mouting file-systems and daemons... And I'm talking about "The GUI controls the file writing in all cases." It doesn't matter what file - forcing people to go through the tool won't be popular. (It doesn't matter that it would be better for them. People are perverse that way.) |> |> The problem comes with dependancies. Which can be either addition |> |> > Which means that the dependancy can never alter appearance - i.e. if |> > I have a service which is dependant on having having the automounter |> > running, I can't replace amd with whizzod. |> |> Basically. Or the package (or installer) needs to know enough to know |> if this is a valid substitution. Which they had better know anyway |> if they want it to work. Which is much easier to do if you have abstract sequence points which can be things like 'remote filesystem clients started and mounted'. Then the dependant client doesn't need to know about amd or whizzod at all - only that if there are any remote filesystems, they will already be mounted. |> > Furthermore, your dependancies will be on specific services, not a |> > class of service. (E.g., you will be dependant on 'nfsd started', |> > not on 'all remote file system servers started'. The rc?.d scheme, |> > with identified sequence points, allows for a higher level of abstraction. |> |> We're back to run-levels. Or simply making the dependency on the last |> item in chain. Or if we have a cluster of items, having a marker |> in the control file define the end of the cluster. Or making the entire |> cluster a single startup item. Last item isn't necessarily right. Assume two services, A and B, both dependant on C. The sequence turns out to be C, A, B. Now a third service, D, comes along which is dependant on both A and B. In a last item scheme it will come after B. Which is fine until something happens that reverses the order of A and B (perhaps A becomes dependant upon B) now the sequence will be C, B, D, A; which isn't what you want. Sequence points could be implemented in a control file by having sequence numbers in addition to or in place of order-in-the-file. |> There are lots of options. |> |> |> And I really can't see a difference between correctly using a |> |> tool to add a line to a file, and correctly using a tool (the |> |> file system) to add a numbered script to a directory. Either |> |> you use it correctly or not, either it's written correctly or |> |> not. If not, you're in a world of hurt either way |> |> > Two differences. The first is the complexity and safety of the tool. |> > a startup script |> > editing tool would be a new, special-purpose tool. |> |> Yep. Just a new and special purpose as the startup mechanism itself. So you want to add a new startup mechanism AND a new script install tool. That's still more system complexity than just a new startup mechanism. -Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9509261600.AA00748>