Date: Tue, 26 Sep 1995 00:41:18 -0500 From: Jon Loeliger <jdl@chrome.onramp.net> To: Gary Palmer <gary@palmer.demon.co.uk> Cc: hackers@freebsd.org Subject: Re: ports startup scripts Message-ID: <199509260541.AAA04042@chrome.jdl.com> In-Reply-To: Your message of "Tue, 26 Sep 1995 06:09:42 BST." <2649.812092182@palmer.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Boldly stepping into the fray, Gary Palmer scribbled:
> >When I first saw the SVR4 model on a Solaris box, it was SO confusing; I
> >thought it was needlessly complex and difficult to comprehend. But when I
Ditto, HP/UX. Not certain and could be wrong here, but I think
HP/UX might have opted away from the S/K variants and went towards
the single script for both roles.
> 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!)
>
> 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).
>
> 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?
Well, I think these issues point to the more generalized problem
of simply representing the "dependency graph". All of the file number
schemes and the single control file schemes are implementations of
the general concepts of linearizing a dependency graph.
Can we have a more abstract representation of that dependency graph?
Can each package state "ordering information" based on either some
absolute package/script references or some virtualization of concepts?
Each dependency has its script or script-fragment somewhere.
Then, either at like, install or boot time (ick) a topological sort is
done on the graph and the script/script-fragment is linearly ordered
and executed.
The algorithm is data driven based on package parts supplied during
the install and a well-defined although not necessarily unique ordering
can be determined.
There are issues here still, like, how do you state dependencies against
things that have yet to be invented? I think that's why fictitious or
virtual nodes may be needed in the graph too. They can essentially
arbitrarily represent the "levels" or "states" in the graph where
certain properties are available ("NFS", "LAN", "WAN", "Single User").
Tip-toeing back out of the warzone,
jdl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509260541.AAA04042>