Re: Why isn't console-cyrillic part of console-data?
>On Tue, Jul 27, 2004 at 09:55:39AM +0100, Alastair McKinstry wrote:
>>
>> I think some of the stuff in console-cyrillic should be merged
>> into console-common post-sarge; console-common is due for a
>> rewrite: mostly to debconf' the font, etc. settings,
>> but also make it more robust.
>I see that many of the fonts in console-data (not only the Cyrillic)
>have multiple variants for different encodings. Is this intentional or
>due to the history of the package? All fonts in console-cyrillic have
>different faces and use some custom artificial encogings. The real
>encoding is chosen by ACM.
The collection of fonts and keymaps in console-data is
mostly historical rather than planned.
>> Conversely, some of the cyrillic fonts/keymaps in
>> console-data may be better off in console-data;
>
>It is possible to optimize the fonts and keymaps in console-data. The
>problem is that all maintainers of this package added stuff to it but
>only on request and after negotiations. As a result some of the files
>in console-data are rarely used and some languages and keyboards are not
>supported at all
>I think we should not base the debconf questions on the existing data
>but develop them in some generic way. Then the files that are necessary
>to support the configurations handled via debconf should be in
>console-data. All other files are obviously rarely used and should be
>moved in other packages.
>
>> the idea should be console-common as standard, with
>> console-tools | kbd choice, and console-data | console-cyrillic.
>
>At present console-cyrillic is an alternative of console-data. In
>sarge+1 I'd like to see this package not as an alternative but as a
>complement - all important stuff is in console-data and console-cyrillic
>is one of the packages containing the less used data.
>
>Another variant is this: two packages console-data-base and
>console-data. The first contains the important data and the second more
>rarely used files. In this way console-cyrillic can be obsoleted.
I favour minimising the amount of console data in base,
but console-data should always be present: think of a
blade system without console, but someone hotplugging a
monitor and keyboard in; for most of its life we don't need
all the data currently in console-data, but some of it
we'd need in a hurry to debug issues.
There is also the Unicode data in /usr/share/unidata; thats
a 1.4 MiB chunk that we rarely need ..
I think console data should be optimised into
console-data, console-data-optional, console-cyrillic.
>Ofcourse in both of these packages the data should be well organized. If
>you want I can help with this. I am not happy with the current state of
>console-data.
Help appreciated, especially on the fonts end. I had not planned
on much work for fonts for sarge+1; If I get
console-common / keyboards sorted out in a 6 month
release cycle, I'll be very happy.
>> loadkeys should work with use X keymaps.
>
>This is great! Do you know who will work for this and how it will be
>implemented?
I'd volunteered for this.
Apparently the X code is now modular enough that I can
dynamically link in code to parse the X keymaps.
I intend to do this:
- separate out the keymap parsing code from loadkeys / kbd-chooser. Move it
into libconsole. One code base.
- Create a wrapper to load the X keymap parsing code in the same
way, so loadkeys can load X keymaps.
- "Merge" the console-data and X keymaps, so that we only
need one set eventually.
With loadkeys / dumpkeys we can dump the keymap
(to /etc/console/boottime.kmap.gz) so that
we don't need X keymaps or X to boot..
but we only need one keymap selection (X's) and to set the
keymap once (possibly speeding up booting into X).
>Anton Zinoviev
>
Regards
Alastair
Reply to: