1 files changed, 34 insertions, 0 deletions
diff --git a/debian/Rationale b/debian/Rationale
new file mode 100644
index 0000000..b30d823
--- /dev/null
+++ b/debian/Rationale
@@ -0,0 +1,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