[Pkg-kbd-devel] Re: pkg-kbd project on Alioth to maintain kdb Debian package

[Konstantinos Margaritis]

On Κυριακή 18 Σεπτέμβριος 2005 22:43, Denis Barbier wrote:
> Hi,
>
> Alastair planned to orphan console-tools and have it replaced by
> kbd after sarge release.  AFAICT this has not been done yet.  I
> suppose that we are both too busy to deal with these packages, and
> believe that we need more people involved, which is why you are
> Cc'ed. (If you know other people which may be interested, please
> forward this message)

I forward this to the Debian-Edu list, I believe they might be 
interested.

> I created the pkg-kbd project on Alioth for this purpose.  If you
> are interested, please subscribe to the pkg-kbd-devel list, and
> let's discuss kbd issues there.  Here are examples of issues which
> could be discussed:

I am interested and just subscribed. My username in alioth is markos.
At this particular time I'm quite busy, but I intend to be able to 
devote more time on this subject soon.

>   * kbd and console-tools have forked a long time ago, how to
> include fixes from both branches?

First, we have to make an actual plan of what we want to do.
Although in theory I'd prefer a clean design from scratch rather than 
an ambiguous mix of both packages, perhaps in reality this might not 
possible right now. I haven't seen both packages in depth so I can't 
know which offers the best design, but from my (small) experience on 
the subject, here's what I think we need:

* A universal way to setup console fonts and keymaps, regardless of 
the actual locale. While I have my doubts for Asian locales, I don't 
think it serves us much purpose in the long run to have a multitude 
of packages that handle console font setting differently for each 
locale.
* This way should take some things for granted and use a common way 
such as used in the Debian Installer, namely use the 4 different 
levels of languages (see recent post of  
Christian Perrier in d-boot):

	* level 0: only displayed in ASCII environments. This includes C and
English
		- No/minimal setting for console required.

	* level 1: Latin-1 languages. These will be displayed when the
environment is Latin-1 only (actually non serial consoles with no
framebuffer)
		- Will need special font setting and keymaps for all VCs.
		- It will not require special console features (eg. keymap 
switching), though it will require keymap setting.

	* level 2: most languages except those requiring special processing 
that make them undisplayable in the most common text environment with
frambuffer, or for which glyphs are currently missing in bterm-unifont
		- This level will require console font setting (for all VCs)
		- It will probably require custom keymaps and console switching.
		- We should probably divide these further according to the locales, 
eg. maybe incorporate code from console-cyrillic and jfbterm to the 
new kbd package. My guess is that we will have 3 more sublevels in 
level2:
			* Locales which can use the normal console font setting, but 
require custom care for keymaps (eg. keymap switching, right-to-left 
writing, other?). Most Eastern European languages probably fall into 
this category, probably Greek and Hebrew as well. 
			* Cyrillic locales. In my understanding these are probably fit in 
the above subcategory, but I'll refrain from doing that statement as 
I'm not familiar with the actual intricacies of setting up the 
console for Cyrillic. If possible the console-cyrillic code should be 
merged into the 
			* Locales that require more complex font handling, such as the 
Asian languages (Japanese, Chinese, etc). Still, I don't think the 
handling should be different, rather we should just use a different 
terminal (jfbterm/bterm? I'm not sure what's the difference between 
them really).

	* level 3: all languages. Will be used in the graphical installer
		- These are by definition not usable in the console and can be 
ignored.

So we have 3 levels, out of which 2 levels only require configuration 
(1 and 2) and for these there are just two things to configure:

* fonts
* keymaps

Assuming that UTF-8 is used universally, this should make things 
easier for us actually and spare us the effort of having to handle 
different encodings. In my opinion, I don't think we should even 
bother to support older encodings for the console. Just go UTF-8 all 
the way.

Also, we should probably make sure (if they're not already) that all 
keymaps are UTF-8 friendly, usually this will just need a conversion 
somewhere to work.

My point is that we should refrain from using a multitude of hard to 
debug switch statements in huge scripts but rather have a high level, 
object oriented (yeah i know it sounds trendy but that's not what the 
point i'm trying to make), at least as much as possible, modular 
approach. Perhaps, we should even rewrite the tools in some more 
powerful language than shell (Perl/Python?). Or maybe there is a way 
to do such stuff in shell, i don't know i'm not a shell guru.
But I don't want just to offer a solution and leave myself out of the 
hard work. I'll try to help as much as I can for the chosen path, 
whichever it might be, though personally I'd like to push for a clean 
approach.

>   * Fix bugs reported against kbd and console-tools related to init
>     scripts.

I believe with proper design most of the bugs will just get solved, 
but of course we should take note of them in the new design.

Konstantinos