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

Re: Reducing the complication of choices in console-setup udeb config: first thought



Quoting Samuel Thibault (sthibault@debian.org):

> I'd even say, one language/country, one layout. Note for instance
> french, for which there are a lot of layouts, from BE, CA, CH, FR,
> ... But there is little chance getting wrong when taking the country
> into account too.  That's why I proposed to first have a list for each
> country/language pair. Then a list for each language can be used if the
> user is not happy with the former.

My point was *not* about showing a different list to users depending
on the language they selected.

It was just about building *one* list that would offer users all
"reasonable" choices.

> > Here is what I come with (to be completed...I stopped at Kazakh):
> 
> No need to do it by hand, it can be automated from xkeyboard-config's
> data.  Any divergence from a hand-written version is just a bug in
> xkeyboard-config.

I don't really see how such a list could be derived from
xkeyboard-config. What there does tell me that I need a keymap for
fr_FR, another for fr_BE and fr_CH or fr_CA....while de_DE and de_AT
are happy with the same one?


> > probably around 70 for i386|amd64 and much much less for
> > arches where there is a need for a dedicated list
> 
> Why a dedicated list?


Because I see this as the only way to keep things simple. We would
then have to just maintain that "selection" of "common" keymaps.

This is about the same method we're using, now, in console-data: c-d
has a big bunch of keymaps for each architectures (admittedly a lot
for i386) out of which we "select" a few to be presented to users in a
single question in D-I (while configuring the regular package sticks
with a multi-level configuration process).

My proposal indeed means creating a specific console-setup-udeb.config
that would be *very* simple: asks just one question and set
console-setup/* accordingly.

After this initial discussion, I think I roughly have the needed
scheme in mind and I can probably write down a patch with these
ideas. Hopefully, I'll get enough time for this in the next weeks.



Attachment: signature.asc
Description: Digital signature


Reply to: