From owner-freebsd-hackers Mon Sep 25 15:34:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA26113 for hackers-outgoing; Mon, 25 Sep 1995 15:34:38 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA26104 for ; Mon, 25 Sep 1995 15:34:33 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA05992; Mon, 25 Sep 1995 15:29:53 -0700 From: Terry Lambert Message-Id: <199509252229.PAA05992@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Mon, 25 Sep 1995 15:29:52 -0700 (MST) Cc: patl@asimov.volant.org, terry@lambert.org, gryphon@healer.com, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com In-Reply-To: <199509252127.RAA13404@healer.com> from "Coranth Gryphon" at Sep 25, 95 05:27:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3072 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > +> 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.