Frans Pop <elen...@planet.nl> (11/02/2010): > Thanks. I was going to ask for that. Only i386 should do fine for > the time being.
Alright, I'll stick with this for now then. > > I think my next moves are going to be: > > - Tweaking lowmem case for X (should be easy once I've figured > > out how this and that components in d-i work) > > There is not really a lowmem case for the graphical installer. Just > a point at which it falls back to using the newt frontend instead of > the gtk frontend. Memory usage is not the main issue for the > graphical installer; Ok, fine, I won't investigate this then. Should the need arise, it should only be a matter of passing an extra parameter when starting X anyway. > initrd size is. I'll explain more in other mails. FWIW, I've tried to reduce it a bit right after having generated the first round of udebs: on amd64, it moved from 17 to 24-25MB, and then down to 21MB once I've rebuilt the remaining bits using DirectFB against X11. > > - Fixing the build of the fbdev driver to get 2 proper flavours > > (should be easy), and maybe having a look at the HACK/TODO bits > > I've left along the path in the various git branches/standalone > > patches. > > You mean deb and udeb? That would be great. And the same goes for > other new packages too. Almost anything that can be disabled at > compile time is worth doing. IMHO this should be the main focus for > now. Yes, I meant that. For now, Julien added a new flavour for xserver-xorg-core-udeb, to disable as many extensions as possible. The fbdev driver then wasn't quite happy, but instead of enabling XV server-side again, I went the dirty way for now: #if 0/#endif around the XV-related calls in the driver. What I meant exactly was turning this into a less dirty solution: using a conditional, and doing a build with DISABLE_XV=0 for the deb, and one with DISABLE_XV=1 for the udeb (instead of disabling XV unconditionally for both, which is the current “implementation”). I'm not yet sure which packages could benefit from that, but gtk is probably going to be an interesting one: it sounds like we could drop some of the X libs it depends on, although the needed configure switches might not exist yet. It looks like Josselin is not afraid of that though; if you want to send me patches, I'll gladly see how it goes from a udeb point of view. For some udebs, I included data “blindly” by merging e.g. - libX.install - libX-data.install into: - libX-udeb.install since libX had libX-data in Depends. Some bits are probably not needed, so we might lose a bit of weight here. > > - Trying to integrate console-setup properly this time, so that once > > one has set it up once in d-i, preferences can be fed directly into > > the installed system, so that one doesn't need to answer the very > > same questions again. Even though console-setup might chosen in the > > end (although it looks like the way to go to tweak X), that's going > > to be a good exercise for me. :) > > That's a fairly big issue. Please have a look at the > post-base-installer script for kbd-chooser which already does that > if kbd-chooser is used in D-I (basically it preseeds console-setup > in the target environment based on the keyboard selection in D-I). Ok, thanks for the pointer. > I'd say that using preseeding is a more obvious solution when > console-setup-udeb is used than when kbd-chooser is used as the > questions should be the same (and thus also the desired values). Yes, that's what Julien and I had in mind. > But my general opinion remains that console-setup-udeb does not yet > have the quality we want for D-I I guess it's never too late to propose help? Maybe there's a list of open issues that an outsider like me could work on? > More on that in a later mail as well. Alright. Mraw, KiBi.
signature.asc
Description: Digital signature
