File: Rationale

package info (click to toggle)
console-data 2:1.12-5
  • links: PTS
  • area: main
  • in suites: jessie, jessie-kfreebsd, stretch
  • size: 6,388 kB
  • sloc: sh: 3,272; pascal: 472; makefile: 231; perl: 168
file content (34 lines) | stat: -rw-r--r-- 2,139 bytes parent folder | download | duplicates (9)
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