Re: Review of console-setup wrt D-I [very long]
On Friday 26 June 2009, Anton Zinoviev wrote:
> 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.
Both the way they are implemented and the total number of strings.
> > 2. The totally insane /usr/share/c-s-mini/c-s.config file
> > ---------------------------------------------------------
> 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.
It still leaves the problem that several mechanisms D-I won't work. One of
them is removal of particular languages *at build time* of installer
images.
> I think the current implementation is both simple and easy to maintain.
IMO it's more important that c-s conforms to the normal way of handling
templates, strings and translations.
> And if compression was used, the strings would ocupy less space than if
> they were in debconf database.
Only if you'd also _access_ the strings compressed. And you still have the
problem of basic package and initrd size.
The only real solution is reduction of strings by focussing on
functionality that is actually needed for an installation.
BTW, I'd still like to see a cdebconf database backend developed at some
point that would allow the templates file as a whole to be compressed.
> I am not sure if Choices-C can be used by console-setup. Is there
> Choices-C outside d-i?
debconf supports it as well (otherwise I would not have suggested it).
> > 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.
No, it is a major bug because if it were solved it would mean at least the
strings and translations needed for keymaps that are not included would
be excluded as well. This contributes significantly to the size problem.
Also, how can you call offering choices that are not supported and for
which the installation of the keymap is going to fail a monir bug?
> > * A script that gets sourced should not have a shebang.
>
> To which script are you refering?
/usr/share/c-s-mini/c-s.config is sourced from the postinst.
> > 2. Keyboard detection
> > ---------------------
> > 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.
I'm not sure how well it is supported or if there is existing software
that uses it, but for USB some keyboards may support the 'bCountrycode'
field:
Bus 001 Device 006: ID 05a4:9841 Ortek Technology, Inc.
Device Descriptor:
idVendor 0x05a4 Ortek Technology, Inc.
idProduct 0x9841
[...]
iProduct 1 USB Compliant Keyboard
[...]
Interface Descriptor:
[...]
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
[...]
bCountryCode 0 Not supported
> 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.
Wrong. Expert mode is not a licence to just throw any random question at
users. They still have to make sense in the context of D-I.
A number of the questions currently being asked IMO do not.
Also, masses of users who run D-I for the very first time will choose
expert mode, even if they don't need it.
We can all thank M$ for that because with Windows and Office choosing
export mode is in general the only way to make even basic selections of
how you want stuff installed.
> > 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.
Why is that? My point is that for most questions we can set correct
defaults that will work for 99% of users and there is no need for them to
see the other questions.
And obviously we'd need some mechanism that would ensure the questions
would not get asked when the regular package gets installed later during
the installation. The should only be asked if the user chooses to
reconfigure the package from the installed system.
[...]
> > 4) altgr key
> > 5) compose key
>
> You omited some questions for the non-Latin scripts. :)
Blame the fact that I only did 15 minutes worth of testing ;-)
> > 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.
But for 99% of users there _is_ a good default. And even for Russia I'd
say that we can perfectly select a *working* and generally accepted
default and leave it up to the user to select something else *after* the
installation if he really wants to.
If that is not acceptable, then let's identify those cases and *only* ask
the question then, maybe displaying simply the name of the character set
instead of a description and thus avoid translations (or only include
translations for those languages for which we display the question).
We don't display such a question *now* and I'm not convinced that we need
to.
> > 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?
Question is very technical; almost nobody will want to change the default;
why confuse users with a question they are unlikely to understand.
Reply to: