Switching g-i from DirectFB to X11

Mon Feb 8 16:33:55 UTC 2010

Hi,

this is a summary of the needed steps to switch from DirectFB to X11.
After some time hacking in the wild, I then looked into providing
(possibly) clean patches for each package, which I've just finished.

I'd like to once again thank Josselin Mouette for the initial idea,
Julien Cristau for his support, especially for the dark X side, as
well as Otavio for his quick answers on IRC.

There's a bunch of pkg-xorg packages that need tweaking, so that they
ship udebs, namely:
  libdrm
  libfontenc
  libpciaccess
  libx11
  libxau
  libxcb
  libxcomposite
  libxcursor
  libxdamage
  libxdmcp
  libxext
  libxfixes
  libxfont
  libxi
  libxinerama
  libxkbfile
  libxrandr
  libxrender
  x11-xkb-utils
  xft
  xkeyboard-config
  xorg-server
  xserver-xorg-input-evdev
  xserver-xorg-video-fbdev

All of them have a pu/udeb branch in their respective git repositories
with the needed tweaks. With some fixes Julien and I are still working
on, some of those go away (libdrm for example is no longer needed with
the new xserver-xorg-core-udeb).

Another round of packages, not maintained by pkg-xorg:
  cairo
  dmz-cursor-theme       (2 patches, tried to save up some space)
  gtk+2.0
  gtk2-engines
  libgcrypt11
  libgpg-error
  pango1.0
  udev                   (maybe a single udeb could be sufficient)
  vte

All of them have patches available there:
  http://people.debian.org/~kibi/patches-udebs-v1/

From a d-i point of view, some tweaks are needed below the packages/
directory:
  cdebconf               (probably worth squashing everything)
  cdebconf-entropy
  cdebconf-terminal
  rootskel-gtk

All of them have patches available there (packages+$foo directories):
  http://people.debian.org/~kibi/patches-di-v1/

I shall note versions in Build-Depends might need tweaking, depending
on which actual versions the added/reworked udebs appear (I think at
least one package got a new revision uploaded while I was working on
my patches).

To build my test image, I had to patch slightly config/amd64.cfg
(partial revert of r61645) and pkg-lists/gtk-common, to enable the
netboot-gtk again, and to add the needed X packages. Since there are
some modules, mklibs can't really figure out where some symbols should
come from, so I've used mklibs-copy thanks to the MKLIBS variable in
config/common, then:

  make (re)build_netboot-gtk

If you were to build a netboot-gtk image using DirectFB, and to
compare with one using X11, one gets:
  DirectFB:  9191 extents written (17 MB)
  X11     : 11239 extents written (21 MB)

Two test images for amd64 are available (with checksums and GPG
signatures, same directory; the last one also has the full output of ):
  http://people.debian.org/~kibi/di-x11/2010-02-06/mini.iso
  http://people.debian.org/~kibi/di-x11/2010-02-08/mini.iso

The first one was built using the udebs generated in my first wild
run, and includes an additional tweak for console-setup, so that
keymap selection also works within the installer.

The second one was built using the udebs generated during the “clean”
run, and doesn't include that tweak, since it seems we will have to
discuss separately the kbd-chooser vs. console-setup issue. There's
also the output of “make stats_netboot-gtk” in the same directory for
that one. (Please keep in mind libraries weren't reduced for that one;
IIRC we would go down from 4.7M libs to 3.3M libs.)

Otavio expressed his concerns about memory usage, I've just finished
an installation in Dzongkha successfully, with a VM limited to approx
128MB. It looks like 96MB weren't sufficient, but we should be able to
tweak some more bits, like using a lower BPP setting for lowmem.

Some things that might need thinking about:

 - Maybe gtk could benefit from a stripped-down flavour instead of
   using the 'shared' one; that might lead to depending on fewer X
   libraries; other patches (gtk2-engines, rootskel-gtk come to mind)
   might need tweaking in this case, so as to use the proper .pc
   file.

 - Maybe libgpg-error and libgcrypt11 could be replaced by
   libcrypto0.9.8-udeb (already used by openssh). One downside is that
   libcrypto0.9.8-udeb is bigger.

 - Maybe think of switching over from kbd-chooser to console-setup. It
   should work (almost) out of the box for X11 (that was at least OK
   with my very first image, before cleaning up my patches), while
   kbd-chooser would mean patching some more. And AFAICT console-setup
   should be able to handle both X and non-X cases.

Why?

 - Josselin explained DirectFB was basically unmaintained, and even if
   he looked around for interested people, he didn't find any. And the
   gtk frontend was even disabled because it was too buggy (r61645).

 - Even if someone steps in to fix some bugs (I heard somebody has
   started to publish some patches recently), it might lead to a
   dependency on a very single person, who might vanish at any
   time. Going the X11 way ensures that we have a few more folks
   working on it on the long run.

 - Using X11 means using something which is daily used by mostly
   everyone out there. Meaning any breakage will be noticed
   immediately.

 - It just works.

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/20100208/c1a63dc8/attachment-0001.pgp>