1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
Parts of IRC log describing rationale to joeyh
==============================================
<lct-debconf> 1. keymaps may be provided by several packages, so descriptions
of all available keymaps should be centralized, accessible by
config scripts. I assumed THE place to centralize was the
debconf db
<lct-debconf> 2. keymaps are described in a structured hierarchical way, so
that the user doesn't get asked to choose among 100 files he
doesn't know about. I selected a "layout family"(eg: qwerty) /
"layout" (eg: US american) / "keyboard variant" (eg: with euro
key) / "keymap variant" (eg: programmer's keymap) scheme
<lct-debconf> 3. questions are asked along those lines, and defined in the
debconf DB as you suggested, or at least as I understood your
suggestion. Problem is, what the postinst finally wants to know
is the keymap filename, which we definitely do not want to show
to the user - at least not as an item in a select list
<joeyh> so your problem is one of mapping from the answers to a filename, when
you don'tknow what all the questions might be
<yann> joeyh: seems to summarize well enough
<joeyh> well, you could just make a package responsible for checking in its
postinst if the answers imply one of the files it contains, and if
so, doing whatever you do with that filename
<yann> joeyh: problem is a package's postinst may have to deal with keymaps
from other packages. Think of installing a new package, user
browsing whether it contains interesting keymap, and finally decides
to use another one. As all available keymaps will be available from
one UI (which is the goal of all this fuss), we can find such
situations
<yann> joeyh: and since the packages are split between tools and data, even
when only one data package is used, only when the 2 packages are
installed should a postinst run install-keymap with data gathered
from debconf
|
