>> Matthew Palmer <[EMAIL PROTECTED]> writes: > Joey said he's only got local file (etc) DBs done. Oh, I misremembered indeed then. > I got the impression that no work has been done on remote databases, > because I've volunteered to write them (at least the LDAP one at this > stage - SQL when I can think up a reasonably sane table structure).
I would hazard guessing that one database, one table per package should do it. Or better said, one table per configuration group/entity. I really don't remember the specification, but I *think* this would allow for a nice trick: store the configuration with an id an have a "snapshot" table, in other words, all the configurations with a given id are time-coherent. Then you could *theoretically* roll back the configuration. It's just an idea and I made it up on the spot, but sounds neat if it could be implemented. > > That'd be the non-interactive front-end. > > I think you misunderstood what I was after. I know the non-interactive > front-end, and it's what gets used at present. What I wanted was some way > to say 'OK, ask me the questions from these packages and then give me the > debconf data (stored in some remote database, preferably) to use on other > machines - but without screwing with the config the local machine.' I see. Yes, that'd be something for debconf-utils. And yes, it'd be useful. > This is what I want, but without needing to configure an actual, > live, running machine. Basically, I want a way to get asked all the > questions and store the answers somewhere without touching the > machine the program is running on. Well, that'd work for the pre-installation phase, but there are postinst scripts using debconf in a sort of interactive way (those that stop in the middle of an install run and pop a debconf dialog up). Those make questions based on the current configuration of the machine, so I'm not sure how that would work. -- Marcelo
