Iustin Pop <ius...@debian.org> writes: > On Sun, Jul 24, 2011 at 01:17:50PM -0700, Russ Allbery wrote:
>> I don't get that impression. Rather, I think both systemd and upstart >> want to significantly reduce the involvement of shell scripts in the >> boot process for the same reason that I'd love to have the time to >> eliminate a lot of them from Debian package maintainer scripts: using a >> (rather quirky with interesting portability issues) Turing-complete >> programming language is only a good idea when you're doing things that >> require that power. The rest of the time, it's much harder to analyze, >> much less adaptable (you're often duplicating work in every separate >> script because helper systems lag, and if there's a bug, you have to >> fix it everywhere instead of in one place), more complicated, and gives >> people enough freedom to get themselves into trouble. > Much less adaptable? Config files are fixed and non-extendable by > themselves. A shell script, because it's Turing-complete, I regard as > very adaptable. We're talking about two very different things. You're talking about adaptability of the init script for a programmer who is modifying it. I'm talking about adaptability of a package already in the archive without requiring someone go do work on it. debhelper is an excellent example. Notice how debhelper frequently just fixes problems in every package that's using debhelper by fixing, say, the generated maintainer script fragment? That's the sort of adaptability that I'm talking about. When you have a simple descriptive language that describes what the service should do, the entire archive can be adapted to many forms of new behavior easily by changing the implementation of that assertion. This isn't possible if the code is implemented independently in every init script; now you have to go modify every init script. I think our experiences across the whole archive have shown that while both cases certainly appear, for Debian as a whole the ability to adapt the entire archive easily to some new circumstance is by far the most common and most important case. >> Falling back on such a language when you have to do something really >> complicated is a good thing to support, but most of the time, you >> really want to use a simple, declarative language that says what you're >> trying to do and then implement the tools and support to accomplish >> that in one, well-tested place. > I have to disagree here. In my experience, most of the time such simple > languages are not enough (down the road), and people will either start > extending and extending them (at which point they're not simple > anymore), or replace the solution entirely. Well, I'm not sure what to say to that other than that my experience directly contradicts yours. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762mrbeew....@windlord.stanford.edu
