[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] Add support for shells in the graphical installer

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.

- 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

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.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: