Previously Raphael Hertzog wrote: > I agree with Ian that each machine should have only one database, > possibly none too (think about a remote db). Why? This is a lot less flexible imho. And it does not reduce the complexity (read my design again). > The DB access should be done through a program call for the packages, > and this program could be configured in order to use a local > or remote database. Which my design already did. > 2. The DB format > > Like a big multilevel hash. That's implementation detail.. > The data consistency should be checked by the postinst scripts either by > checking itself the data or by telling the program that read the DB the > format the data should have. > The simplest way would be to use a directory tree, with the filenames > beeing keys and the contents beeing the data. But other formats should also be supported. This format for example is very bad if you use ext2 as a filesystem. > 3. The implementation in new packages > > We must add a 'config' script (or better 'preconfig') to the > control.tar.gz archive. The preconfig should use a program > dcfgset (his role is to ask data and store them in the database) > whereas the postinst script should use a dcfgget program (this > program would look for the data in the DB and ask the user if data > cannot be found. We can imagine that the postinst might fail if > the install is non-interactive and data cannot be found). 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. > 4. The frontend > > 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. > > 5. Interaction with dpkg / backward compatibilities > > The implementation would be quite easy with my solution. dcfgget > and dcfgset are only interfaces beetween the DB, the user and the > install scripts. 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. > Dpkg needs to be modified anyway in order to support > a --pre-configure flag and possibly --non-interactive flag too. No, the frontend should manage interactivity, it's not dpkg's job. > 6. Packaging problems > > Since the preconfigure script and the part that is in postinst will > be very similar (maybe just dcfgset replaced by dcfgget), a > helper script could automate the process of writing both parts > from only one file. I severly doubt that. > 7. The registry aspect > > 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? Wichert.
Attachment:
pgpzCRBfJe5Vr.pgp
Description: PGP signature