Date: Mon, 25 Sep 1995 15:29:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gryphon@healer.com (Coranth Gryphon) Cc: patl@asimov.volant.org, terry@lambert.org, gryphon@healer.com, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com Subject: Re: ports startup scripts Message-ID: <199509252229.PAA05992@phaeton.artisoft.com> In-Reply-To: <199509252127.RAA13404@healer.com> from "Coranth Gryphon" at Sep 25, 95 05:27:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > +> Yes, this relies upon implicit order (whatever "find" returns), which I > > +> really don't like. But I couldn't see any other option, and if you > > > fairly simple: pick a number after the number of the packages you depend > > on, but low enough that other packages may depend on you without overflowing > > the lexical name space. I'd suggest 3 digits rather than 2 as a guard > > Or use file order, in which case your numbering limit is maximum number > of lines in the file. Again, it quickly becomes a religious battle of > which people prefer - numbered scripts or a control file. > > Personally, I like the control file. I can print it out, and know > exactly what will run in what order. > > You like numbered scripts, you can print out a directory listing, > and know exactly what will run in what order. > > Functionally, they are the same. Issues for the automation are similar > in most cases (getting the ordering right, dependancies, collisions). Functionally, I can union mount my script directory over a read-only template directory to add my local scripts. How do I union two files? > You way requires sym-linked sub-dirs to control the order, mine still > holds to the same master file. The danger of mine is that packages > need to modify the master file, the danger of yours is that packages > need to make sure they put the right files and links in the right places. Creation is arbitrated at the directory entry level in the FS code itself. > > If you think you can present a unified view of all system > > components without seperate scripts, fine, I'd like to see a set of > > libraries for dealing with components. > > Is this a tangent, or missed interpretation? I have always been in favor > of seperate scripts for each sub-system/component/package. I just want > to put them in one place and have them run from a master file, rather > than sym-links to state-based subdirectories. this still doesn't handle the "union of several directories" problem, even if the contents are simply a file, if order of operation is based on file order. > And yes, I'd be very happy a combined mechanism that includes startup of > the various levels, plus the regularly scheduled daily/weekly stuff. > > > I already have a GUI library that will put out the right thing from the > > same program on DOS, Windows, Mac, UNIX Text, Vanilla X, Motif, and > > Great. Given a simple GUI library, I'll even do the GUI's for both parts. > > > I'll give out the termcap/X/Motif libraries. Though I'd prefer a GUI > > based Drag-N-Drop interface, like the Mac System folder concept, I'm > > willing to throw the (IMO) less powerful paradigm out the door to get > > Drag-and-Drop I really think would be frosting. If you have the > libraries for the standard GUI cake, let's go with what we have. > > We can always do a different GUI later. I will get the GUI stuff together for public use by November. 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?199509252229.PAA05992>