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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
