Date: Mon, 25 Sep 1995 11:47:11 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: patl@asimov.volant.org Cc: jmb@kryten.atinc.com, terry@lambert.org, gryphon@healer.com, hackers@FreeBSD.ORG, peter@taronga.com Subject: Re: ports startup scripts Message-ID: <199509251847.LAA05564@phaeton.artisoft.com> In-Reply-To: <no.id> from "patl@asimov.volant.org" at Sep 25, 95 08:53:10 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > 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 one package depended on another having been run first, the dependency would show as an order designator that was lexically prior to the order designator selected for the dependant package. By definition, a dependant package must have the package it depends on (and thus its write must be aware of the depended packages order of initialization). > Or renumber all the other scripts if they do? Never necessary. As I said, a don't care state. > Or come with a list of numbers to choose from? If a dependency graph were needed, then "depends on <package>" and the installation log would have to be consulted. Personally, I think this is unnecessary because of the aformentioned collision/don't-care relationship. > 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 easy for a human that wants to much about in things that should be done via tool in the first place. > > Could this be changed to 'add a file to the scheduled jobs directory', > > to avoid the need to automatically edit a file? > > If you want, put it as "mumble.daily" in /etc/bin and it will be run > automatically. I have a problem with this. My problem is that I want finer control over the granularity as part of the administrative range granted me by the configuration control file I expect to install to allow me to administrate the package as a unified system component in my standard system administration utility. > 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 > were hand-adding scripts you could bloody well get the order right yourself > DESIGNING a system around implicit order I consider reckless. I agree. The explicit ordering required in a lexically ordered system is 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 against overflow, though I expect the lead digit to remain 0 for a long time (if not forever). > And yes, I know that SysV does it, and that is works fine for whoever. > I don't like SysV. Specifically, I don't like this "feature" of SysV. > That's what I run a BSD variant. The feature we are considering is the ability to drop in add on components as if they were system components and provide a unified administrative interface for their control. Currently, we don't have *any* administrative interface (except perhaps 'vi') precisely because there is no unified view of the system which one could import. It's possible to write one, but it'd be a kludge, and we all know it. > It boils down to that. A few other people have said it, and I'll say it too. > I don't want FreeBSD to become a SysV-clone. That's what Linux is for. Neither do I. But don't condemn the idea because of the messenger. A valid idea is a valid idea no matter where it comes from (I feel like I'm teaching phenomenology to bomb #28 8-)). > If people want changes to the startup mechanism, to incorporate the best > concepts from SysV, that's fine. It's call improving. The best concept they had was the ability to component administrative portions of package data so it looked like the package was a part of the OS, even if it came from a third party. The second best concept they had was run levels/states to allow staged "run-up" and "run-down". > But throwing out the entire "rc" script concept, and going with (pick an > implemention, any mutant implementation) SysV-clone I consider bad. What '"rc" script concept"? There's one script, init runs it, and if you don't like the system state after that, tough. Hardly a paradigm. > It also comes down to implementation and support. I'll gladly volunteer > to write and support the version I'm pushing for, and do whatever > the improvements to that base design that people want. > > Will you volunteer the same for your version? Including a re-write of the > "daily/weekly" stuff that reallly should use the same mechanism? I'll volunteer for the administrative utility *if* a unified view is presented. 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. 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 OpenLook, dependent on shared library path (UNIX versions, of course). 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 something started. 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?199509251847.LAA05564>