Antti-Juhani Kaijanaho wrote: > There is a fundamental difference. The new model allows the frontend > make the decisions, based on the constraints set by the package's > configmodule. In the original model the decisions were hardwired into > the configmodule, and if you wanted to change the decisions globally, > you'd have to rewrite every single package there is. In the new > model, such changes require only that a new frontend be written, or an > old one be modified.
I don't understand the meaning of "decisions" you are using. > > Why don't we then just send the frontend a lump of shell code and use that > > as our implementation language? > > Because a shell script is not suitable for describing the complex > structures that result from the nontrivial interdependencies of data > that some packages may require. In other words, a shell script does > not scale well. > > [my illustrative language] > > How is this different from: > [a shell script] > > They do different things. They both instruct the frontend to present the same tree of questions to the user. Ok, here is the one huge, gaping, fatal hole in your poposal. Many config scripts in debian look at the current status of the system, and ask questions based on that. For example, lilo looks to see if the user has edited /etc/lilo.conf. If so, it asks one set of questions, otherwise, it does more probing to find out what is the name of the main linux partition on the system and presents that in another set of questions. Without some program running on the backend, this cannot be done. As I understand your proposal, it does away with the configmodules running on the backend. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
