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

Re: Review of console-setup wrt D-I [very long]



On Wed, Jun 24, 2009 at 08:40:12PM +0200, Frans Pop wrote:
> 
> 1. Package size - impact on initrd size and memory usage

I suppose this is because of the way translations are currently 
implemented.  The keymaps of c-s require significantly less space than 
those of kbd-chooser.

> 2. The totally insane /usr/share/c-s-mini/c-s.config file
> ---------------------------------------------------------
> With no disrespect intended to Anton or Samuel, but reading strings and 
> translations from a sourced script is very simply not an acceptable 
> technical solution. It violates the design principles of (c)debconf and 
> will be a maintenance nightmare for the future.
>
> It also contributes significantly to the size problem as all original 
> strings (or keys) are endlessly duplicated in the file, which they would 
> not be in the debconf database.

The solution I am thinking is to have those strings compressed inside 
the config script.  The script can source itself and decompress the 
strings it needs on the fly.  This also automatically eliminates the 
problem with string duplication.

> I also don't see why the strings cannot be in the debconf database. For 
> example localechooser and choose-mirror also has a number of dialogs that 
> are built dynamically and they all use standard debconf functionality.
> 
> I have not looked deeply, but I don't see why c-s could not do this in 
> debconf, using for example Choices-C, variables and 'register'.
> 
> The current solution seems to me to be a case of "we didn't know how to do 
> it correctly, so we just took an easy way out". But maybe Samuel can 
> explain the actual issues in some detail.

I think the current implementation is both simple and easy to maintain.  
And if compression was used, the strings would ocupy less space than if 
they were in debconf database.

I am not sure if Choices-C can be used by console-setup.  Is there 
Choices-C outside d-i?
 
> 3. Offers keymaps that not available?
> -------------------------------------
> In expert mode I see keyboard models for Amiga, Sun, Macintosh etc. But 
> only the c-s-pc-ekmap udeb is included. How is that supposed to work?

Yes, this is a (minor) bug and unfortunately I don't see an easy fix for it.

> 4. Other technical issues
> -------------------------
> In general I feel that the decision to keep the c-s udeb identical in 
> functionality to the regular c-s package is a bad choice: the installer 
> has different requirements than an installed system.

This reduces the code that has to be maintained.  Imagine what nightmare 
it would be if d-i team had to track all changes in the regular package 
and to reimplement and debug these changes in the udeb.  How many bugs 
would be fixed only in the regular package or only in the udeb without 
realising that these bugs existed both in the regular package and in the 
udeb.

If d-i has different requirements they can be easily coded in the logic 
of the scripts of c-s.  Moreover thanks to console-setup-mini the 
implementation can be tested outside d-i too.

> Separating that properly would also allow the removal of the D-I menu 
> description template from the regular package.

I can not see why this is a problem. :)

> * Does not respect selected choices: on <Go Back> from "layout" to
>   "origin" the default origin is selected, not the choice I previously
>   selected.

I acknowledge this.  Thanks for the observation.  The fix is not difficult.

> * Has the implementation been checked for idempotency?

I hope so.

> * Are previous choices respected when c-s is run a second time?

These choices are written in the configuration file.  Then the values 
from the configuration file are used as defaults.  Yes, this modus 
operandi is somewhat strange inside d-i (how many udebs are configuring 
their own configuration files in /etc) but in the regular package this 
works well so it should work for the udeb too.

> * Coding style: scripts are for example not tab-indented, again wasting
>   memory.
> * Huge (copyright) comments should be stripped out of scripts.

Thanks for reminding this.  Can be fixed easily.

> * A script that gets sourced should not have a shebang.

To which script are you refering?

> * A coordinated effort should be made at some point to get c-s tested on
>   arches other than x86.
> * The number of options in some dialogs make c-s COMPLETELY unusable with
>   the text frontend.

I have no idea what to do about the number of options.  This can be 
fixed only by changes in the frontend.

> 2. Keyboard detection
> ---------------------
> Does c-s detect if a keyboard is connected at all and what type it is?
> Does it change defaults based on that? Or does it just leave everything to 
> the user? The last could be considered a regression.

The model questions is visible only in expert mode and the default is 
based on the architecture/subarchitecture and information in /proc.

> But wouldn't it be nice if the correct keyboard layout could be 
> autodetected? AFAIK a lot of keyboards, especially USB and maybe also SUN 
> keyboards do advertise their layout.

No detection of the model of the USB keyboards is done.  I can try to 
'steal' the detection code if you know what software does such 
detection.

> * In expert mode kbd-chooser also offers an option to skip kbd config.

One extra question to the already big list. ;-)

Seriously, should I add such a question?  What would be its purpose?

> Dialogs are far from intuitive.

I somewhat agree with this.

> In expert mode I completely and utterly lost my way during c-s and 
> even during normal installation there are simply way too many keymaps 
> to choose from.

This is unavoidable (in expert mode).  Anyone who has installed Debian 
in expert mode knows that in most cases simple <Enter> is the the proper 
answer.  The questions of c-s don't change this at all.

> What happened to the design principle of D-I that we aim for a solid but 
> *basic* system installation and that if users want bells and whistles 
> they should configure them after system installation?

Please notice that any question you skip or simplify in the udeb will 
have to be (re)asked by the regular package so there is realy no gain 
for the end user.
 
> Let's have a look (I hope I counted correctly):
> 1) keyboard model, ~150 options ... WTF?

I don't know.

> 2) keyboard origin, ~90 options

BTW, yes - there is special layout for Maldives. :) The only layout that 
supports the divehi script.

> 3) keyboard layout

In many cases the default layout is not only incorrect but also 
unusable.  So yes - d-i needs this question.

> 4) altgr key
> 5) compose key

You omited some questions for the non-Latin scripts. :)

> 6) encoding (shouldn't that just take what was selected in localechooser?)

Yes.  Will be fixed.

> 7) character set (can't we just set a default based on selected language?)

Unfortunately no default is good in expert mode.  For example for most 
languages there is the choice between 256 and 512 character fonts; for 
the people in Russia there are three different character sets and no 
good default, etc.

> 8) console font (bell)
> 9) font size (whistle)
> 10) virtual consoles (this should IMO not even be a debconf question, but
>     just be configurable through the config file)

What is the benefit to make this configurable only through the config 
file?

> If "Netherlands" is selected I get the layout question with:
>    Netherlands
>    Netherlands - Macintosh
>    Netherlands - Standard
>    Netherlands - Sun dead keys
> OK, the last 3 should probably not be there, but "Netherlands" 
> and "Netherlands - standard"? Is "Netherlands" not standard enough?
> Possibly "Standard" should be "Sun Standard" instead?

I have no idea what the difference between "Netherlands" and 
"Netherlands - Standard" is.  Such problems have to be reported 
upstream.

> And why the repetition in this dialog? Couldn't the origin be mentioned in 
> the description with only the variants in the choices list?

Yes, it would be nice to do this but then - what name can be given to 
the first layout?

> Typo in "western Europe and Turkic languages": s/Turkic/Turkish/

No. http://en.wikipedia.org/wiki/Turkic_languages

Anton Zinoviev


Reply to: