On Tuesday 08 July 2008, =?iso-8859-1?B?Suly6W15?= Bobbio wrote: > The attached patchset adds support for shells in the graphical > installer: "Execute a shell" in menu, and rescue-mode shells can now be > used in the graphical installer. Great work Jérémy, but... > The result is quite nice, and the user experience is very similar > between the different frontends. The impact on the current code by > these changes are really low and they should be seen as strong > candidate for inclusion in Lenny. This should really be considered carefully, especially given the timing. As you probably know the freeze for Lenny for libraries is expected pretty soon. Also, the libvte9 udeb is rather big. Even with the reduced size of the udeb we're looking at at least 1MB extra memory usage. From the templates discussion you are leaving open whether or not to include it in the initrd or not. IMO we should discuss that now. Questions: - What is size increase of initrd with this included? - What is memory usage increase immediately after boot if this is included in initrd? - Is there any increase in memory usage if shell(s) are actually started? > http://people.debian.org/~lunar/ttf-dejavu_2.25-1_add_mono-udeb.diff.gz > * libvte9-udeb containing the VteTerminal widget used by the > plugin. > 315kB compressed, 688kB installed > http://people.debian.org/~lunar/vte_0.16.14-1_enable_udeb.diff.gz - Please shorten the long package description for the udeb. - I see nothing in the patch that ensures we'll get correct dependencies on this udeb. > * libncurses5-udeb needed by libvte. > 80k compressed, 172k installed > http://people.debian.org/~lunar/ncurses_5.6+20080614-1_enable_udeb.diff >.gz For this one we need to be careful that others don't start using it for other purposes which may get it included in "normal" initrds. It's not huge, but still. > I can't provide a test image right now as I am lacking the necessary > network connectivity. I will try to provide one as soon as possible. I'd really like to see this before forming a final opinion, especially as it has an impact on the graphical installer as a whole. If you can provide a set of udebs for i386 with no other changes relative to current unstable, that would be fine too. I'll comment on templates after testing. > If there is no strong objections after a first round of testing, I > would like to ask for the changes outside d-i without waiting too much. I think we should only do this if a freeze exception is approved by the release team before the changes are requested. I also think we should get an OK from the libvte maintainer that the patch is OK with him before requesting the other changes. Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.