Re: Configuring a Debian system
Wichert Akkerman <wakkerma@debian.org> writes:
> [1 <text/plain; us-ascii (7bit)>]
> Previously Joey Hess wrote:
> > The templates can be parsed quickly to generate a hierarchical structure of
> > questions you can browse. In the general case, it is impossible to tell if a
> > question is valid without running a script. I can provide examples of this
> > if you need them.
>
> The only way you can build a decision tree (or forest of trees) is if you
> design a new languages for this specifically. (In fact I've made a partial
> visual language for this. It's quite nice but forcing people to learn a
> new language (and a new type of language for most people as well) simply
> isn't an option I think). You will still run into problems when browsing
> remote databases though.
My idea was to use shell as the language, since most people will know
enough to use it. To allow for parsing some restriction would have to
be made. In this case parsing would mean running the shell script in a
sandbox and recording its output. The restrictions would be that all
interaction with the system, e.g. running sed on a file or creating a
user, are marked with a preceding "dpkg-exec", which justs skips the
command inside the sandbox and executes it otherwise. Likewise test on
the system could be preceded by "dpkg-test", so that when
preconfiguring a system one can substitue a proper result for the
test, although such cases shold be rare and kept to a minimum.
>: Previously Joey Hess wrote:
>:
>: Ok, parse was the wrong word. I was just referring to the common computer
>: science precept that the only way to determine if code terminates (and thus
>: what it does) is to run it. Anything that tries to guess what tests a script
>: makes without running it is not always going to get the right
>: results.
Thats the reason for the sandbox, the script should actually get run
just as normal, but alterations to the system must be catched,
otherwise canceling would be timeconsuming and parsing potentially
slow.
>: I realize you've worked around this by enforcing the use of a particular
>: syntax (and a particular language!), but I really hate to tie programmer's
>: hands this way.
The language wouldn't actually have to be fixed, but it would be
hard to tell a general dpkg-exec to execute perl code. One could write
modules for script languages, so the first thing in a config script
would be to include the appropriate module (i.e. source module.sh or
load module.pl). The module could then define the dpkg-exec function
for the language.
MfG,
Goswin
Reply to: