Switching g-i from DirectFB to X11

[Cyril Brulebois]

Frans Pop <elendil at planet.nl> (11/02/2010):
> Thanks. I was going to ask for that. Only i386 should do fine for
> the time being.

Alright, I'll stick with this for now then.

> > I think my next moves are going to be:
> >  - Tweaking lowmem case for X (should be easy once I've figured
> >    out how this and that components in d-i work)
>
> There is not really a lowmem case for the graphical installer. Just
> a point at which it falls back to using the newt frontend instead of
> the gtk frontend. Memory usage is not the main issue for the
> graphical installer;

Ok, fine, I won't investigate this then. Should the need arise, it
should only be a matter of passing an extra parameter when starting X
anyway.

> initrd size is. I'll explain more in other mails.

FWIW, I've tried to reduce it a bit right after having generated the
first round of udebs: on amd64, it moved from 17 to 24-25MB, and then
down to 21MB once I've rebuilt the remaining bits using DirectFB
against X11.

> >  - Fixing the build of the fbdev driver to get 2 proper flavours
> >    (should be easy), and maybe having a look at the HACK/TODO bits
> >    I've left along the path in the various git branches/standalone
> >    patches.
>
> You mean deb and udeb? That would be great. And the same goes for
> other new packages too. Almost anything that can be disabled at
> compile time is worth doing.  IMHO this should be the main focus for
> now.

Yes, I meant that. For now, Julien added a new flavour for
xserver-xorg-core-udeb, to disable as many extensions as possible. The
fbdev driver then wasn't quite happy, but instead of enabling XV
server-side again, I went the dirty way for now: #if 0/#endif around
the XV-related calls in the driver. What I meant exactly was turning
this into a less dirty solution: using a conditional, and doing a
build with DISABLE_XV=0 for the deb, and one with DISABLE_XV=1 for the
udeb (instead of disabling XV unconditionally for both, which is the
current “implementation”).

I'm not yet sure which packages could benefit from that, but gtk is
probably going to be an interesting one: it sounds like we could drop
some of the X libs it depends on, although the needed configure
switches might not exist yet. It looks like Josselin is not afraid of
that though; if you want to send me patches, I'll gladly see how it
goes from a udeb point of view.


For some udebs, I included data “blindly” by merging e.g.
 - libX.install
 - libX-data.install
into:
 - libX-udeb.install

since libX had libX-data in Depends. Some bits are probably not
needed, so we might lose a bit of weight here.

> >  - Trying to integrate console-setup properly this time, so that once
> >    one has set it up once in d-i, preferences can be fed directly into
> >    the installed system, so that one doesn't need to answer the very
> >    same questions again. Even though console-setup might chosen in the
> >    end (although it looks like the way to go to tweak X), that's going
> >    to be a good exercise for me. :)
>
> That's a fairly big issue. Please have a look at the
> post-base-installer script for kbd-chooser which already does that
> if kbd-chooser is used in D-I (basically it preseeds console-setup
> in the target environment based on the keyboard selection in D-I).

Ok, thanks for the pointer.

> I'd say that using preseeding is a more obvious solution when
> console-setup-udeb is used than when kbd-chooser is used as the
> questions should be the same (and thus also the desired values).

Yes, that's what Julien and I had in mind.

> But my general opinion remains that console-setup-udeb does not yet
> have the quality we want for D-I

I guess it's never too late to propose help? Maybe there's a list of
open issues that an outsider like me could work on?

> More on that in a later mail as well.

Alright.

Mraw,
KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20100211/cd30fe94/attachment.pgp>