Re: Review of console-setup wrt D-I [very long]
On Fri, Jun 26, 2009 at 09:27:48PM +0300, Anton Zinoviev wrote:
> On Wed, Jun 24, 2009 at 08:40:12PM +0200, Frans Pop wrote:
> > 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 agree with Frans - this is just weird and this sort of thing belongs
in the debconf database. Note that cdebconf knows how to throw away
translations for languages it isn't using once it gets to a certain
point in the installer - there would be no sane and straightforward way
to do this if they're all embedded in a script.
If we desperately need to make the cdebconf database smaller after
adding console-setup translations to it, then we can look at doing that
centrally and benefit everything at once, rather than having it done
independently in console-setup. (For example, we could consider some
kind of interning of strings so that duplicates between languages only
need to be stored once; that would benefit localechooser too since
country name translations are often common to several languages.)
> I am not sure if Choices-C can be used by console-setup. Is there
> Choices-C outside d-i?
Yes, debconf has had this since version 1.5.5 (September 2006). There's
no excuse for avoiding Choices-C these days. :-)
> > 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.
I agree; I wouldn't want to have to maintain a separate version of this.
One of d-i's highest design goals was always to share code with the
installed system, and we should think very carefully each time we
propose diverging from this.
I'm not sure Frans was actually suggesting a separate implementation,
though, rather than merely conditional behaviour.
> > 2. Keyboard detection
> > ---------------------
> > Does c-s detect if a keyboard is connected at all and what type it is?
Surely these days (2.6) the kernel maps them all to something vaguely
common. We shouldn't have to concern ourselves with the keyboard type in
any significant way any more, except for a small number of exceptions
(Brazilian, Japanese, special hotkeys, etc.) which wouldn't be
autodetectable anyway.
> > 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.
This is utter wishful thinking, I'm afraid, at least for USB.
http://lists.freedesktop.org/archives/xorg/2004-August/002472.html
Sure, it would be lovely to be able to do this. In practice, it just
doesn't work. Keyboard manufacturers are too cheap and the standard is
hopelessly inadequate anyway.
> > * 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?
I suggest a special choice in one of the existing questions (perhaps
layout or model). The purpose is to cope with situations such as serial
console installations where setting a keyboard layout is pointless and
IIRC may even fail; you might as well just leave things whatever way the
kernel sets them up.
> > 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.
Some things could be got rid of on both sides, IMO.
> > Let's have a look (I hope I counted correctly):
> > 1) keyboard model, ~150 options ... WTF?
>
> I don't know.
I think we should stop asking this question entirely. Hardly anyone
really needs anything other than pc105, except for the Brazilian and
Japanese cases that can be derived automatically from the keyboard
layout anyway. In most of the crazy manufacturer-specific cases, you're
better off using the mappings in hal-info to assign actions to
specialised hotkeys. (See https://wiki.ubuntu.com/Hotkeys/Architecture
for some discussion of this.) Doing this in console-setup does not seem
very usable to me, even though some of the facilities are technically
offered via XKB.
> > 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.
Agreed on both counts. Stripping down the list is only good in cases
where there aren't actually any keyboards of that type, in which case
what are they doing in xkeyboard-config anyway ...?
> > 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.
Some day we'll have kernel modesetting everywhere and a usable,
lightweight framebuffer console without silly limitations on font
rendering, right? </pipe-dream>
> > 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?
The unspeakably vast majority of people only want setupcon to operate on
tty[1-6]. This is way beyond what expert mode should bother offering. We
don't have a debconf question in expert mode to actually run gettys on
other consoles - it's something you have to set up yourself, and rightly
so.
> > 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.
There are a fair number of differences between those two variants in
/usr/share/X11/xkb/symbols/nl, albeit mostly at higher shift levels. I
agree, this should be taken up with XKB upstream if it's an issue,
rather than us carving out our own little silo.
> > 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?
GNOME's keyboard layout configuration tool hasn't figured this one out
either. In the absence of a sane answer, perhaps it would be best for
console-setup/variant's description to point out that if you don't know
what to do then the first choice is usually a good one.
--
Colin Watson [cjwatson@debian.org]
Reply to: