Re: OEM-Install for Debian?
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 [cjwatson@debian.org]
Reply to: