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

About console-setup in d-i


Frans Pop asked me to comment the possible switch to console-setup.

On Thu, Apr 26, 2007 at 06:12:18PM +0200, Frans Pop wrote:
> I'd also appreciate if you and the other console-setup developers could 
> give some thought to switching from kbd-chooser/console-data to 
> console-setup for D-I, which is a goal for Lenny.

I think this can be done in two stages.  

The first stage is this: (a) make the Cyrillic languages use
console-setup instead of console-cyrillic and (b) use console-setup
for even more languages (such as Vietnamese and all non-Latin
languages) the same way currently the Cyrillic languages use
console-cyrillic.  I will be more than glad to be able to obsolete
console-cyrillic so I don't have to maintain similar functionality in
two packages.  Console-setup is already better and more universal than
console-cyrillic and it also seams very easy to maintain.

This first stage is very simple and it is a pity that it was not
complete for etch.

The second stage is the full deployment of the udebs of console-setup.
Currently these udebs are disabled but I can enable them as soon as
you tell me.

> Can you give some idea of what would be needed? Some questions I have:
> - would we still need kbd-chooser, or is there a replacement

We need it only during the first stage; the udebs replace it.

> - how much development would be needed

For the first stage very little development is needed - we simply use
console-setup instead of console-cyrillic.

The most important change in d-i before the udebs of console-setup can
be used is that console-setup needs 'loadkeys'.  This means that the
console maintainers will have to make an udeb with loadkeys.

The other change is inside localechooser.  Console-setup needs
information about the encoding of the selected locale, or else it has
to ask the question about the encoding with critical priority.  If
localechooser sets a template such as debian-installer/locale-encoding,
this should be enough.

I think that is all that needs to be done outside console-setup.  If
d-i uses console-setup, then all console-related stuff can be (but
doesn't need to be) removed from localechooser.

The most difficult part inside console-setup is to make the
model/layout strings translatable.  The X upstream provides
translations in a xml file but I have no idea how to use them.

> - how are the various architectures supported

Currently they are not supported well due to problems with the X
keyboard data.

I believe in the next couple of days I will be able to upload a
package that will equally support all architectures.  My solution
relies on an alternative version of the X rules file (instead of
/usr/share/X11/xkb/rules/base) and because of that I will need people
who use non-PC keyboards to test it.

Unfortunately my alternative version of the rules file can not be
accepted by the X developers because it makes the PC keyboard layouts
default even on macs.  Fortunately I will be able to override these
bad defaults when the debconf questions are asked.

> - does console-setup solve the "keyboard architecture" problem (e.g. that 
> usb-mac keymaps are really only for Macintosh keyboards, while most USB 
> keyboards have plain AT-keyboard keymaps)

Yes, it does.

> - are there any known or expected issues

I think the Ubuntu developers can comment here because the Ubuntu
installer uses console-setup and as a result currently there are more
Ubuntu users of console-setup than Debian users.

> How much help can the console-setup developers give us with the switch for 
> D-I?

Currently console-setup developers = me + the developers of Ubuntu who
adapted the package for Ubuntu, discovered and fixed several bugs and
tested the udebs.

This is what I can do:
   - any required development and bug fixes.

This is what I can not do:
   - to fix the bugs promptly (for example translation-based uploads);
   - to test the existing udebs (while I wrote them, all tests and
     bug-fixes were done by the Ubuntu developers).

Fortunately I wrote the udebs in such a way that they contain no more
than 10 lines of code that are not used in the standalone packages
also. :)

Anton Zinoviev

Reply to: