Re: Why isn't console-cyrillic part of console-data?

[Recai Oktas <roktas@omu.edu.tr>]

* Kenshi Muto [2004-07-26 22:00:22+0900]
> At 26 Jul 04 11:35:32 GMT,
> Recai Oktas wrote:
[...]
> > The difference mainly comes from the fact that each of the console
> > handling packages mentioned above needs special treatment and we should
> > leave this task to the most eligible developer, that is, the one who use
> > that type of console in his/her real life.  By this argument, I must say
> > that the console-jfb should be maintained by a Japanese developer
> > (Kenshi?).  That way, such console problems could be quickly spotted
> > and fixed.  I think this fact also ensures the modularization when we
> > consider it in d-i.
> 
> I may misunderstand your opinion, but jfbterm is completely different
> with console-data and console-cyrillic.
> 
> - jfbterm is just terminal application as same as bterm.
>   It uses framebuffer and is independent of console-*.
>   Because this is application,
>   - normal-user can't launch up X Window System from here.
>   - it can't provide as console by init script.

I'm aware of some of these facts.  But then isn't there a problem here
which I'm going to try to explain?  As for the current situation we try
to introduce the end user with a _completely localized_ console (or a
terminal wrt jfbterm) after the installation has finished (and without
any extra effort to correct the localization problems -- #250789).  I
mean a barebones (but localized) environment, since he/she may prefer to
install X Window System or other stuff later or may be contented with it
(due to the, say, machine resources).  As I understand you correctly, it
seems that the jfbterm is merely considered as a wrapper to display
second-stage messages in Japanese (or other relevant languages).

Regarding the X Window launch up problem with jfbterm, I can't suggest a
solution at the moment, but we could surely work on this issue.

Regards,

-- 
roktas