Re: Switching g-i from DirectFB to X11 -- image size; library reduction
On Wednesday 24 February 2010, Cyril Brulebois wrote:
> Frans Pop <elendil@planet.nl> (19/02/2010):
> > 1) every MB pushes other packages off the 1st full CD and DVD.
>
> While I can understand the ultimate goal, I'm not sure saving a few kB
> here and there is going to make such a difference in the end. (As you
> noted in a xulrunner bugreport, Recommends can drag a little bit more
> than what's exactly needed…)
Well, the xulrunner Recommends have now been fixed :-) (And so has a
totally crazy Recommends in w3m that was only relevant for Japanese users
but pulled in emacs, ruby, pango, cairo, dbus and quite some X...)
But also, debian-cd currently does not take Recommends into account when
deciding the order in which packages should be included on CDs.
And I'm not sure it should. Using only Depends _should_ still result in a
working system. Also considering Recommends is always going to pull in so
much that it will not really improve the ordering.
Keeping CD size down is a fight you can't win. Do you remember that for
Woody (and maybe Sarge) we installed both GNOME and KDE from a single CD?
Thats's no longer even remotely possible.
But it's also a fight you can't give up on and 4GB can be *a lot* of
smaller packages...
> > 3) reduces portability
>
> Anyway, netboot-gtk was only enabled for i386, amd64, and powerpc,
> IIRC. Maybe the next one could be enabled for more archs if we keep
> the size low enough to meet the size limitation?
Yep, that's what I'm hoping. And also that we can have it more stable for
powerpc and thus also offer it for CD installs.
> > Why memory usage is less important
> > ----------------------------------
>
> Alright, just had a look at the memory requirement for the X11-based
> image since this 64MB bar was mentioned on IRC.
If that's so it was mentioned incorrectly.
The current limit where D-I falls back to the newt frontend is ~92MB, as
can be seen in lib/debian-installer.d/S60frontend (rootskel).
> > How image size could be reduced
> > -------------------------------
>
> I tried to do so, but the final size didn't go down as expected.
> Moreover, it seems like every algorithm is quite tied to libgpg-error
> calls, so I couldn't really get rid of it there.
[... comments snipped ...]
> If that doesn't sound to bad, I could:
> - Provide a patch against libmatrixssl1.8-dev so that it ships the
> appropriate headers, maybe in a special location so as to avoid
> cluttering the usual include paths
> (/usr/include/libmatrixssl/onlyforthebrandnewshinyXudeb)
> - Patch xorg-server a bit more so that the main build happens against
> libgcrypt and so that the udeb build happens against this new
> libmatrixssl version, building statically against it.
Thanks a lot for looking into alternatives. I think the technical solution
that's best decided by you and the X.Org folks.
> The second step isn't ready yet, but I already have Xorg built against
> libmatrixssl (for both flavours as of now). According to debdiff, the
> Depends on libgcrypt11-udeb goes away, and the final size for the
> xserver-xorg-core-udeb doesn't seem to grow up too much:
> | Installed-Size: [-2012-] {+2032+}
That looks very good, if compared to ~260kB for gcrypt + gpgerror.
> I guess that finalizing the set of udebs needing work is the most
> important thing to do right now; then finalizing the patches against
> all of them; then lowering the overall size by optimizing
> (e.g. through lib reduction). What do you think?
Agreed.
Reply to: