I am planning to finally integrate base-config properly with d-i. This will involve copying the d-i debconf database to somewhere in /target, probably var/cache/debconf/installation/. In my tests it looks like cdebconf writes the database quite frequently (suprisingly frequently, really), so getting the full db should not be a problem. Then base-config will look at some entries in the config and translate them over to the installed debconf database. It's also possible that I may decide to just have base-config merge the two databases into one. This has some advantages, but also problems, especially if there are question nameing conflicts. One such possible conflict is with, of all things, debconf/priority. high is default in d-i, while medium has historically been the default in debian proper. debconf/frontend is also used by both, but the set of frontends differs and would at least need to be translated. But wouldn't it be nice to be able to boot d-i and on the boot line, tell it to use the text frontend, and low priority (power user settings (or is that critical? :-)) and have that carry through right into the installed system.. Which brings me to boot-time parameters. We have a few, but I think they ought to be rethought. It would be neat if they could be used to override any value in the debconf database, not only the ones it has special environment variables for. So you could boot with debconf/priority=low, or with debconf/language=foo or maybe mirror/distribution=sid. These actually will show up as environment variables, though the shell cannot access them very easily because of the slash, all it needs is a little program to translate these into the cdebconf database and mark them as seen. There are also a few boot parameters (that I added) that have no corresponding question in the cdebconf database, and I should probably try to fix that. The cdebconf datbase then becomes a fairly self-documenting means of overriding lots of the installer's behavior. Of course overriding it at the boot prompt doesn't meet the needs of large installations that need to pre-seed the whole database, but it's a start. Finally, my more oddball idea. d-i drops a few files into various places in /target, and there is no easy way to know you've found them all and cleaned them all out of your installed system. Since we're already much better in this regard than the boot-floppies with their unpackged kernel, I think we could take it a step further, and make sure everything is in a package of a sort. This "package" could be assembeled on the fly somehow toward the end of the installation (or it could be a regular package that is installed as usual but then it cannot own some files as easily), and when purged would delete the log files, clean out the copy of the d-i database (or if base-config merges the two databases, purge the d-i parts from the main database), and so on. -- see shy jo
Attachment:
signature.asc
Description: Digital signature