Le Wed, Nov 11, 1998 at 02:13:56PM +0100, Wichert Akkerman écrivait: > 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.
I may have mis-expressed something here but you answered that to Ian's mail (18 Aug 98 23:05:43 +0100 BST): ---- > (2): (b) makes it hard to overwrite a whole category of data. For > example, supposing I want to say `discard all local config data for > the MTA, and fetch it from <machine> instead'. With (b) I have to be > able to express that in the config file syntax, and then delete it > from the config file again later. With (a) that becomes an explicit > operation. That's a good point. ---- FYI (b) is having a set of db. > Which adds an extra step to the process that is not necessary imho. With only one local db, i add an extra step before starting the installation. With multiple sources, the extra step is added each time dcfgget is called ! It certainly is not totally true because you may have a cache mecanism or the information may be found in the first source, but you see what I mean. > 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. Having only one local database is not intented to simplify the dcfgget program, it was for other purpose (cf. the top of the mail). > 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.. [...] > My design also used scripts, so I don't see why this would be more flexible. So where's the problem ? For simple configuration the script may be used as a simple text file... like I explained it in the previous post (remember cat <<EOF | preconfigurator ... EOF). > ooh.. you just invented recursion. Can you image how many processes there > will be if someone move forward and back again 50 times? Really, the design can allow it in a different way... ie. propose a list of package that have to be preconfigured and select which one to jump to or which one to preconfigure.. > And I see no reason such a configuration database (or registry if you > prefer that name) should be limited to Debian.. Me too, but in fact I doubt that other distribution will install/package this configuration database just for launching some Debian-specific programs... :) Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
