Re: Towards X11-based d-i: v2, final report
Sorry for not replying sooner. If there had been anything really urgent I
would have commented, but there wasn't.
I did look at the new image and udebs earlier, but did not get around to
doing a full review until now.
The difference in image size between version 1 and 2 is about 400kB
(smaller), but because of the alpha release and kernel switch there are
many other factors then just X.Org udebs.
More relevant is that it is now only 15% instead of almost 19% larger than
a current directfb based image would have been, which is a significant
improvement IMO.
The main components of the 400kB difference are roughly:
- reduced size of X.Org related stuff: -/- 565kB
- dropping of dhcp3-client-udeb: -/- 166kB
- new kernel:
- general increase: 225kB
- increased size of mouse-modules (bug fix): 8kB
That >0.5 MB improvement is well worth the effort. Thanks.
The new udev udebs look good as well.
I think with this all the obvious fat has been trimmed and errors resolved.
Things I did notice:
- libx11-6-udeb: still contains a man page
- libx11-6-udeb: some (most/all?) of the included locales are probably not
needed; the en_US Compose file is huge and the one for Finnish is insane
considering it's only for a single language - what if all langs had a
file like that...
- xserver-xorg-video-fbdev-udeb: depends on libc6 instead of libc6-udeb
- udev-gtk-udeb: long description is a bit weird; I'd expect the last
sentence together with the first sentence and not dangling at the end,
and the "additionally" does not really make any sense
On Saturday 27 February 2010, Cyril Brulebois wrote:
> Various remarks:
> ================
>
> * I had to disable speakup since the related package isn't available
> right now after the 2.6.30 → 2.6.32 switch. Sorry about that. I
> might generate another “v2” image once this package is available,
> though.
Speakup is just a minor detail in the context of this change. Don't worry
about it.
> * Previously I was building against squeeze, but with that same
> kernel version switch, I had to enable both squeeze and sid in my
> sources.list.udeb file.
It's much better always to build against sid when doing development work
for D-I. For our purposes testing is much less reliable.
> * I'm now generating the minimal XML file for the MIME database in a
> cleaner fashion, using an XSLT transformation.
Nice.
> * It might be possible to get rid of some X libraries by linking
> statically against them, but that would mean more work, possibly
> additional flavours, etc. I'm not sure the gain (if any) would be
> as high as for the server (see previous report), though. I'd tend
> to think it'd be more maintainable on the long run to keep the
> current set of udebs than trying to reduce it as much as
> possible.
It would only make sense for libs
- that are only depended on by one other udeb
- that's of a non-trivial size
- for which most of its symbols are not actually used
I think that with libgcrypt we've already got the most obvious candidate,
although the gain seems to have been less than I would have expected.
> Things for later:
> =================
>
> * Deal with cursors, including supporting theme switching.
IMO the default cursor is fine. Theme support is more relevant, but as
mentioned before I think it's realistic to ask the accessibility people to
look into that.
> * Probably get rid of refresh_keymap() in cdebconf.
I would make me very unhappy if we don't have correct keymap setup in both
the graphical (or D-I) environment and on the VTs for the debug consoles.
I can see that refresh_keymap() is maybe not the correct implementation to
achieve this, but something should.
Debug shells are an essential feature of D-I, for both development and
rescue.
> * Dive into mklibs.
I've thought of that a bit more and come up with a snag.
mklibs will only work if the pic files 100% match the library that is being
reduced. So there's a problem when libs in D-I are configured differently
from the regular libs, or if they have other libs compiled in statically.
It can be solved in two ways:
- have special *-udeb-pic debs (which should conflict with normal -pic debs
- do library reduction in a chroot of the image instead of using the host
system
The second option has the added advantage of making a build less dependent
on the host system (for official builds it could pull -pic *udebs* from
testing instead of installing them on the host system), but it also means
a fair complication of the build process and probably that builds would
always need to be run as root (either real or sudo).
I would add:
* Reduce the duplication that exists between console-setup and X.org udebs.
As per: http://lists.debian.org/debian-boot/2010/02/msg00771.html
Cheers,
FJP
Reply to: