From owner-freebsd-hackers Mon Sep 25 19:49:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA06331 for hackers-outgoing; Mon, 25 Sep 1995 19:49:06 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA06316 for ; Mon, 25 Sep 1995 19:49:01 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id TAA14955; Mon, 25 Sep 1995 19:47:37 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA29658; Mon, 25 Sep 1995 19:53:15 -0700 Date: Mon, 25 Sep 1995 19:53:15 -0700 Message-Id: <9509260253.AA29658@asimov.volant.org> To: terry@lambert.org, gryphon@healer.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk |> From: Terry Lambert |> >>> Ah, but can you guarantee that the install script that inserts a |> >>> few new lines is putting them in the right place? |> > |> >+> Can you guarantee that the install script is going to get the numbering |> >+> right if we go with implicit order based upon script name? |> |> > Yes, actually. By using a sparse numeric order designator at the front |> > of the name to enforce ordering by strict lexical (numeric) order. Like |> > numbering your lines by 10 or 100 in a BASIC program. |> |> Like it adds to the end of the file. Or adds to the first (or fourth or ...) |> line after its dependancy. If it can find the dependancy. And doesn't mistake something else for it. Which basicly means it will work fine in the lab and fail miserably in the real world. I have yet to see an automatic editing system which was robust in the face of manual editing of the target file. Particularly when the manual editing is being done by less experienced sysadmins that might not know about the peculiarities of the automatic system... |> > +> Or worse, is every install going to check to make sure that no other |> > +> scripts exists which use that order number? |> |> > No. Because the number is not the only designator. By definition, |> > collisions in order designation are "don't care". This is because if |> |> Again, you can always append to the file if it is a "don't care", |> unless we are allowing additions that MUST come before other things |> that already exist in the startup sequence. I can think of it happening, |> though I'd like to see ANY automated sequence deal gracefully with it. |> And if it does, the same logic can be applied to the file edit. It's a matter of how simply the logic can be applied. With the numbered file technique, it is generally a simple matter to nail down the sparse sequence points that are likely to be significant (NFS started, etc.) Once that has been done, the install scripts can be written with a priori knowlege and hard-coded sequence numbers. In the file editing case, the installation script must be able to recognize the proper insertion point by examining the file at run time. (And if that doesn't scare you, think about scripts trying to automatically -remove- services from the script. If you still aren't scared, you haven't been a sysadmin for long enough.) |> It really boils down to perference of style, and... Well, if you want to consider safety a point of style... |> > +> I think these are a LOT more dangerous. File order is explicit |> > +> and simple. Anything else is headaches. |> |> > You are not expected to manually edit the data. If you want to, fine: |> > you deserve headaches. The point is to make it easy for the tools, not |> |> It always comes down to a person trying to figure it out when something |> is wrong. I'd rather spend a little more time making the tools smarter, |> so that a person has an easier time of it, than making the tools stupid, |> and hoping the person is smart enought to work around that. |> |> That's the whole point of everything we're doing. Give the average |> person on the street a system that they can understand and maintain. |> Personally, I'd rather me (the designer/programmer) spend the time to |> make their lives easier, since that generates a larger customer/user base. Great plan. But in this situation, it suffers badly from diminishing returns. You are talking about implementing a complex installation and removal system to allow for a run-time system which only appears simpler. I predict that your installation system will -never- be a solid, safe, easy-to-configure-and-use mechanism; because it will have to be too complex. |> Make things so that only long-time sys-admins with a serious understanding |> of OS concepts can debug this, and such free OS's will die. Actually, I find the SysV/Solaris2 technique -easier- to understand and work with. |> > +> 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. No, it isn't a purely religious battle over preferences - it is a very real battle over safety-and-simplicity -vs- perceived-simplicity and tradition. |> 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). |> |> 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. And I submit that my dangers are significantly less severe than yours. |> > The second best concept [SysV] had was run levels/states to allow staged |> > "run-up" and "run-down". |> |> I still like linear run-levels, rather than arbitrary states (and think the |> former would be a LOT easier to implement). Now we're closer to a religious issue :-) (And I think the implementation difference is minor.) -Pat