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

Re: [D-I] Please test Debian Installer with console-setup (3rd version)

Quoting Anton Zinoviev (anton@lml.bas.bg):

> > I have not seen any single "Georgian" keyboard in my entire computing
> > life in France.
> Actually fr(geo) is not for Georgian keyboards.  It is for typing 
> Georgian on a French keyboard.

My point.... There is no such physical keyboard. Apparently, from what
you mention, various keyboard layouts are added, more or less
randomly, because someone once worked on one. This is about the same
crazyness we had with console layouts in the good old days, where
everybody was inventing his|her own "layout" (fr-latin1, fr-latin9,

If upstream xkb has such policy, I'm afraid it is entirely entering a
neverending nightmare of piling up "layouts" and "variants" for each
and every crazy ideas in the world.

Anyway, this is getting off-topic. I'm not in position to change XKB
policy, nor do I want it. 

Here, I'm interested in the consequences we have in D-I....

> > > layouts, but with time this filtering will become so distant from what 
> > > the upstream is providing us that it will become a nightmare to support 
> > > it.
> > 
> > I see absolutely no reason for this. I'm proposing to just make that
> > choice each time a language is added to D-I. We're doing this for
> > years (actually since D-I exists).
> Console-data was maintained by you, i.e. by a member of d-i team. My 
> concern is that Xkeyboard-config changes more rapidly than console-data.

As said, the point is not changing xkeyboard-config. The point is in
still keeping the idea of "the same keyboard management system in D-I
and, later, at the system's console, than the one in X"....while
keeping this manageable and scalable for D-I.

> BTW, it seems to me that there is no other file in XKB with such a 
> diversity of variants as the French file. :) I don't know whether all 

The German one is also quite interesting....which is not a surprise:
we find there the very same mess we have in console keymaps, inherited
from the days where people where thinking it is good to "invent" their
own keyboard layout and publish it everywhere because it was working
on their own kitchen sink...:-)

BTW, this is what I personnally think about those crazy Dvorak keymaps
but don't tell this to the Dvorak and Bépo keymaps addicts..:-)

> these variants are realy used or not, but if they are not, one method to 
> deal with this mess is to mark some of the variants in the file with the 
> keyword "hidden".  In this way these variants will be still supported 
> but the configuration programs will not present them to the users.  If 
> there is agreement between the French users, the upstream can be 
> convinced to make the changes.

I'm not sure that belongs to upstream, again. We should refocus on our
point, here: D-I. I'm not interested in changing things upstream, or
even changing the way you deal with them in the standard console-setup
package. You're certainly handling things the right way. 

The point is the udeb. I'm currently convinced and still need to be
unconvinced that we have to shrink the number of proposed layouts to a
list with only 1 or 2 layouts per language, plus some country-specific
cases (e.g. the Brazilian layouts). That means having a specific way
to ask for layouts *in a single question* mor eor less combining the
layout/variant (and maybe model) questions. This only in D-I. Probably
with a specific console-setup-udeb.postinst script instead of using
the big cs-.postinst and c-s.config scripts.

I see this as the only way to preserve one key feature of D-I: keeping
things simple for users and minimizing the number of asked questions.
And, also, preserve the rationale where "size matters".

Attachment: signature.asc
Description: Digital signature

Reply to: