Re: Switching g-i from DirectFB to X11 -- specific issues/comments
In this mail some more specific issues I noticed while testing/reviewing.
I'm saving the switch to console-setup for a last separate reply.
On Monday 08 February 2010, Cyril Brulebois wrote:
> libx11
Is /usr/share/X11/locale needed? If it is, could some of its contents be
excluded because they are not relevant for G-I?
Contains a man page which should be excluded.
> xserver-xorg-video-fbdev
Contains a man page which should be excluded.
> libgpg-error
This udeb includes .mo files. The whole /usr/share/locale directory should
be excluded (but see also my "image size" mail).
The same (.mo files) also goes for xkb-data-udeb.
> dmz-cursor-theme (2 patches, tried to save up some space)
Could probably be reduced further. A lot of cursor shapes will never be
displayed. For example: at least currently we have no need for window
moving and resizing.
AFAIK only arrow and text are actually used. It would be nice to have
"wait" as well (e.g. while building dialogs or when progress bars are
active), but that would probably require changes in cdebconf.
The directfb G-I displayed a smaller black arrow, which IMO was more
elegant than the one displayed now.
Keeping the white as option could be useful for e.g. the "dark" theme, but
that means we'd need a way to change the cursor.
> udev (maybe a single udeb could be sufficient)
I suppose the additions really are unavoidable?
The problem with the current patch is that udev-udeb depends on the new
libudev-udeb and will thus also get pulled into regular installer images
and increase their size.
So I'd prefer to concentrate all bits that are only needed for G-I to be
combined in a separate udeb (udev-gtk-udeb?) and leave the existing
udev-udeb unchanged. udev-gtk-udeb should then depend on udev-udeb and one
of the xorg udebs should depend on udev-gtk-udeb.
Hopefully that's acceptable for Marco.
Point of attention is whether we want the persistent input rules to get
copied to the installed system (as we already do for persistent net
rules).
> 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
This was an important issue. Glad that's resolved for now. But as Bastian
noted the current workaround can cause problems if a module were to be the
only user of some libc symbol. So we definitely need to look at his
suggestion to force all symbols to "weak".
> 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.
IIRC 96 MB is the current limit for the directfb based installer. But that
is a very generous setting. If 96MB is tight, it should be raised. Reason
is that installs using loads of stack (xfs on LVM on crypto on RAID...)
should also be guaranteed to work.
Reply to: