Previously Raphael Hertzog wrote: > Read Ian's argument. This design make it difficult to say : "Now I > want to remove all mail-transport-agent/* keys". Sorry to say this, but this is complete and utter nonsense. The only difference was if you used a virtual database that can consist of multiple sources or a single database. How you access that database is the same for both ides. > And the need to have access to multiple database can be done through a > database merging. Which adds an extra step to the process that is not necessary imho. > Of course. The only thing to do is to change the dcfg program and add > support for other DB. So you win nothing: either you have a very complicated dcfg program or a couple of frontends that use a somewhat complicated library implementing the same. > 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"... We don't want to write scripts unless it's necessary evil. For a *lot* of packages the questions are so simple a script is complete overkill.. > 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. My design also used scripts, so I don't see why this would be more flexible. > Huh ? The program that does call dpkg --preconfigure can provide a way > of lauching dpkg --preconfigure for the next/previous package. ooh.. you just invented recursion. Can you image how many processes there will be if someone move forward and back again 50 times? > And how would it be managed by your system ? Since the frontend is lauched > every time by dpkg, the same problem exist... Indeed. I was going to fix that :) > 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 ? So? I never said the implementation couldn't use a textfile. In fact I explicitly said you can have different formats so the user can choose which he wants by simply editing a textfile that lists the driver. > 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. And I see no reason such a configuration database (or registry if you prefer that name) should be limited to Debian.. Wichert.
Attachment:
pgpn59W96hx4A.pgp
Description: PGP signature