Comment 11 for bug 558593

An alternative is that it may be possible to have a simple X progress
bar using debconf-apt-progress and debconf's GNOME frontend. Neither
would be particularly pretty, but they would be better than a black
screen with various errors on it.

For what it's worth, while I'd like to improve the user experience here,
at this point I'm only considering options for which the code
substantially already exists and which are already known to be robust
and functional, requiring only to be glued into oem-config. Anything
else is more risky than just pulling the feature. Although
debconf-apt-progress, whether with an ncurses-style frontend or an
X-based frontend, is not going to be seamlessly integrated into the user
experience provided by the rest of oem-config, it has the virtue of
being a known-good component usable for this kind of thing and I don't
think anything else is likely to be done in time with an acceptable risk
of regressions.

If both of these approaches are unacceptable, then I think we have no
alternative but to default oem-config/remove to false and thus return to
the previous situation where oem-config was left on the user's system
after configuration (bug 210779). I have a slight reliability concern
here, because I'd really rather get rid of oem-config's Upstart job
entirely rather than risk it being accidentally run again later when it
shouldn't be, and so I think this option carries its own problems.
Still, it's possible.

(As Robbie's IRC log notes in passing, the problem with trying to
integrate smoothly into oem-config's UI is that we're in the process of
ripping out all of oem-config's files from under it. Thus, IMO any
option that involves removing oem-config before most of oem-config has
exited carries a risk, which is why I'm not really comfortable with
doing it in the normal package removal hooks at this point. I would be
happy for us to experiment with that for Maverick.)