Re: Configuration management / proposal
Le Wed, Nov 11, 1998 at 02:18:56AM +0100, Wichert Akkerman écrivait:
> Why? This is a lot less flexible imho. And it does not reduce the
> complexity (read my design again).
Read Ian's argument. This design make it difficult to say : "Now I
want to remove all mail-transport-agent/* keys".
And the need to have access to multiple database can be done through a
database merging.
> Which my design already did.
I didn't say the contrary. I just pointed out the facts that are important
imo.
> But other formats should also be supported. This format for example is
> very bad if you use ext2 as a filesystem.
Of course. The only thing to do is to change the dcfg program and add
support for other DB.
> This moves a lot of complexity into the config-scripts, like deciding
> which questions should be asked and which should be skipped. Remember
> we want to have multiple levels of interactivity.
In a way or in a other, you must specify what questions have to be asked,
and i don't know what would be more difficult, write an appropriate script
or describe the questions and set a "priority to a question"...
And by the way, the preconfig script does not suffer from having to
be backward compatible, so if you do not want to write the script and you
prefer to use an other, we wan imagine having a tool (beeing in base)
that could parse the type of file you would like to setup.
The script approach _is more flexible_ in all the cases. It allow those
who want to manage all themselves to do it and other to use
helper programs.
What about such a preconfig script ?
----
#!/bin/sh
set -e
cat <<EOF | preconfigurator
Question: Do you want to test ?
Type: boolean
Key: package/test
EOF
----
> > It is called by the scripts themselves not by dpkg. It's better
> > this way, I think. The little need of interactions can be
> > managed with exit code / simple stdout values.
>
> No: this would make it impossible to move to the next/previous pacakage.
Huh ? The program that does call dpkg --preconfigure can provide a way
of lauching dpkg --preconfigure for the next/previous package.
Otherwise a special errnum returned by dpkg --configure can explain
him that we want to go to the previous/next.
And how would it be managed by your system ? Since the frontend is lauched
every time by dpkg, the same problem exist...
That's really not a big problem...
> The database should support more, for example native Debian packages
> could use it directly. So we want to have for example DBI and C
> interfaces as well.
Look at the response I give about windows-like registry further.
> No, the frontend should manage interactivity, it's not dpkg's job.
Right. But that's not a problem. We only need a way for the dcfgget
program to know if interactiveness is allowed or not.
> > I'm against using this configuration database as a windows-like registry.
> > This db should only be used for installing packages. It is not intented
> > for beeing a big configuration file for software that could access to
> > it through an API.
>
> Why not?
I do not feel well, when I can't edit configuration with a rescue floppy
and vi. And what about if a guy doesn't want to install dcfg*.deb ?
Should the package using the db as configuraion file depends on it ?
Well, i don't like all those centralized things that become "essential"
with the time if you want to use some simple programs... and furthermore
i don't like Debian programs becoming more and more Debian specific.
Cheers,
--
Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Reply to: