Hi,
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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
