From a8cb957231734308a424bc87a111ab7e3ef72a94 Mon Sep 17 00:00:00 2001
From: P. J. McDermott <pjm@nac.net>
Date: Wed, 11 Jan 2012 01:07:25 -0500
Subject: Define problem of multiple and split packages.

---
diff --git a/multiple-and-split-binary-packages.txt b/multiple-and-split-binary-packages.txt
new file mode 100644
index 0000000..db37854
--- /dev/null
+++ b/multiple-and-split-binary-packages.txt
@@ -0,0 +1,37 @@
+PROBLEM CASES
+=============
+
+CASE 1: MULTIPLE BINARY PACKAGES
+--------------------------------
+
+Some source packages generate multiple binary packages, each of which is built
+independently.
+
+The source package format as defined by the current draft specification supports
+this case well.
+
+Example 1: Linux
+The source package for Linux will generate image and headers packages.
+
+Example 2: BusyBox
+Some hardware vendors may wish to use a custom BusyBox configuration to better
+suit their users' needs.  The source package for BusyBox may generate multiple
+builds of BusyBox, each with its own configuration.
+
+CASE 2: SPLIT BINARY PACKAGES
+-----------------------------
+
+Some source packages generate multiple binary packages, some or all of which
+come from a single build of the packaged software.
+
+The source package format as defined by the current draft specification does not
+support this case.
+
+Example 1: GCC
+The source package for GCC will generate binary packages to provide a C
+compiler, support libraries, a C preprocessor, etc.
+
+Example 2: A library with debugging symbols
+All binary packages should be stripped of debugging symbols, however many
+(especially library) packages may provide debugging symbols (extracted after the
+build using objdump) in a separate and optional binary package.
--
cgit v0.9.1