On Thu, Mar 13, 2008 at 09:32:57AM +0000, Matt Zimmerman wrote: > On Wed, Mar 12, 2008 at 11:58:00PM +0200, Eddy Petrișor wrote: > > This *looks* really like is Debian Installer with some additional module > > and some supplementary package. (Note that I said "looks", but I haven't > > dug into the issue to see if it really is D-I). > > > > If, indeed, is a modified Debian Installer, I guess we could get the D-I > > module and add an option to boot with such an option. Ditto for the > > package(s) in the system. > > > > Matt, most likely, can confirm or infirm the assumptions above :-) . > > I can't take personal credit for this bit of technology, but yes, can say > that yes, it is built on debian-installer. Colin Watson is the primary > author, and would be a good point of contact for someone interested in > helping to get this upstream.
I'd be happy to have a go at this, but it needs a fair amount of work in merging changes to dependent components first, notably localechooser and console-setup. I'll probably have a crack at these merges after the forthcoming Ubuntu release is done (I'd intended to anyway). I would definitely appreciate any work on this being coordinated with me. oem-config is still under fairly active development, though not perhaps as frenetic as it was at one point, and we have considered merging it into the same package as the Ubuntu desktop installer (ubiquity), which might make it tricky to package in Debian. A different approach which would be easier from that point of view would be to progressively split out some of the lower-level Python components. I'd also like to continue maintaining it in Bazaar rather than moving it to d-i svn (as I did with kickseed). oem-config is not really just a d-i module, as Eddy suggests above. You cannot boot into it in the same way that you can boot into d-i. Its purpose is to be installed on an ordinary system and to be run by a user the first time they start up their computer after receiving it from their vendor. It uses a good deal of d-i code to do its job, but is more akin to a strange sort of frontend than an ordinary d-i component. The main "interesting" bit of oem-config, from the infrastructure point of view, is its approach to debconf. In order to produce a hand-designed UI rather than the generated UI produced by things like the cdebconf GTK frontend, it interposes itself between the debconf confmodule and the debconf frontend; I called this new component a "debconf filter". When the confmodule requests the answer to a question using INPUT, the filter blocks the confmodule for a while and passes control to the UI, which will often wait for user input, but may be able to answer straight away if several questions are being presented at once. The same technology later became part of ubiquity. This technique is extremely powerful; it is demonstrably sophisticated enough to be able to produce a working graphical partitioner with partman as a backend but with a significantly different frontend design (without LVM, RAID, or crypto as yet, but those should be possible), and is used in oem-config to present user interfaces for selecting locale, timezone, keyboard, and user; the timezone interface includes a map on which you can select your city, the keyboard interface has two parallel list boxes representing layout and variant, and so on. That said, it has some drawbacks too. Writing debconf filters is very challenging, and the failure modes are difficult to diagnose. In some ways a filter acts like a robotic user, "pressing buttons" at the underlying d-i component in response to the designed UI. If it loses track of the state machine in the d-i component, things go badly wrong. If the d-i component doesn't have much in the way of a state machine to start with, driving it this way is very difficult, and can sometimes be slow (though not critically so). Changes to d-i require corresponding, sometimes laborious changes to oem-config. Assumptions about the d-i environment in d-i components no longer hold. GUIs often require instant updates of logically-connected components (such as the keyboard layout and variant lists mentioned above), and doing that by waiting for confmodule code to iterate back and forward through a state machine tends to be far too slow, so sections of code need to be copied and the copies maintained. I've had to make a number of (usually subtle) changes to d-i components to make this work, and in some cases I have been obliged to duplicate or rewrite code. While I am happy with the top-level design and largely happy with the results, the internals are really quite (unintentionally) developer-hostile in some ways, very unlike d-i's developer-friendly construction. It definitely isn't the sort of package that maintains itself. Some day, I would like to figure out how to improve this while meeting similar goals. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
