Re: State of graphical installer

[Colin Watson <cjwatson@debian.org>]

On Tue, Sep 28, 2004 at 12:53:09PM +0200, Martin Schulze wrote:
> State of graphical installer
> 
> Does anybody know the current state of the graphical installer?  Using
> debconf for d-i was said to have the benefit of hooking different
> frontends to it and the gtk/gnome frontend is one of them.
> 
> Michael Cardenas also provided the first version of a graphical
> installer a couple of years ago (1-2) but I don't remember any
> progress or work being done to it.
> 
> Is anybody interested in reviving it and working on a graphical
> installation method?

I'm busy trying to revive it, and most of my time at Oldenburg was spent
doing this. I'm working on the following immediate issues:

  * cdebconf-gtk has bitrotted

    gtk.c hasn't been touched since March, and it shows; it spends a lot
    of its time segfaulting or misbehaving in other ways. I have a
    series of patches in my queue to clean it up.

  * several udebs are only built on i386

    I'm developing on powerpc, and there are a number of GNOMEish udebs
    that are only built on i386 due to an accident in debian/rules. Bug
    reports will be forthcoming tonight.

  * directfb udebs are a nightmarish mess

    The directfb and gtk+2.0-directfb udebs are laid out very strangely;
    I think they reflect some very old ideas on how to do udeb library
    packaging. As they stand, they thoroughly confuse mklibs (kov posted
    a patch to work around this, but the libraries really need to be
    fixed). They need to be repackaged in a more normal way, with
    ordinary runtime and development debs and a runtime udeb.

  * mklibs issues

    Even after I experimentally repackaged directfb and
    gtk+2.0-directfb, I still ran into issues with mklibs reporting lots
    of unresolved symbols. I'm still investigating; help from somebody
    who knows mklibs well would be appreciated.

    (So, as it stands, d-i only builds with the gtk frontend if you beat
    it up a lot one way or another.)

  * cdebconf extensions

    We almost certainly need some cdebconf extensions to allow us to
    make the GTK frontend a good user interface; I think the ability to
    register a callback that gets triggered when the answer to a
    question is changed (but not necessarily OKed) would be a good
    start.

-- 
Colin Watson                                       [cjwatson@debian.org]