[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> 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: