Frans Pop <elendil@planet.nl> (19/02/2010): > I'm saving the switch to console-setup for a last separate reply. (It's late^Wearly but) Did I miss it? > > 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? As replied by Julien, some space saving could happen, probably candidate for the 3rd step of the plan proposed in the last paragraph of <[🔎] 20100224071921.GA29099@debian.org>[1]? 1. http://lists.debian.org/debian-boot/2010/02/msg00704.html > > xserver-xorg-video-fbdev > > Contains a man page which should be excluded. Already done in my pu/udeb-clean branches on alioth. > > libgpg-error As per [1], gone. > The same (.mo files) also goes for xkb-data-udeb. Will have to check that one. > > 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. Could you please establish a normative list of the cursors you're using or going to use (which would then include the “wait” one), so that we only keep those? > The directfb G-I displayed a smaller black arrow, which IMO was more > elegant than the one displayed now. I for one don't care that much; I only picked this theme since Josselin mentioned it initially; BTW, there's DMZ-White & DMZ-Black in the same (regular deb) package, we probably could arrange something, especially if we're going to ship only a few cursors. > 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. At (d-i, not udeb-providing-source-package) build time, I assume? In both cases, it's just about a link to create before X starts. > > udev (maybe a single udeb could be sufficient) > > I suppose the additions really are unavoidable? Already addressed by Julien in his reply. > 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. Whatever works for Marco and -boot folks. Only a few additional items are needed and have been spotted, so shipping them in this or that udeb should be trivial. > 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". As noted in [1], I'd rather keep library reduction for later, but that sounds like something we want to do at some point indeed. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature