Re: Configuration management, revision 3
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 debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: