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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002190747.30282.elen...@planet.nl
