From 7e13eabe0d129549668ffd22ebb02e8f35d84fe0 Mon Sep 17 00:00:00 2001
From: P. J. McDermott <pjm@nac.net>
Date: Mon, 16 Jan 2012 20:04:54 -0500
Subject: Document package configuration handling.

---
diff --git a/package-application-configuration.txt b/package-application-configuration.txt
new file mode 100644
index 0000000..23d0834
--- /dev/null
+++ b/package-application-configuration.txt
@@ -0,0 +1,92 @@
+ABOUT THIS DOCUMENT
+===================
+
+This document describes the proposed handling of application-specific package
+configurations.
+
+
+LEGAL NOTICE
+============
+
+Copyright (C) 2012 Patrick "P. J." McDermott
+
+This document may be reproduced, distributed, modified, and otherwise dealt in
+under the terms of the Expat/MIT License:
+http://www.jclark.com/xml/copying.txt
+
+
+SPECIFICATION STATUS
+====================
+
+This specification is in draft status.  It is a work-in-progress and is subject
+to change.  Comments and revisions are welcome.
+
+
+INTRODUCTION
+============
+
+Hardware vendors and other system distributors may wish to configure certain
+software packages (especially Linux) at build time and/or run time for their
+hardware and their applications.  It must therefore be possible for end users to
+install software packages configured for their hardware and application
+platforms and for package maintainers to build software packages configured for
+platform targets.
+
+
+RATIONALE
+=========
+
+It makes sense to use opkg's architecture logic to support building and
+installing binary packages for specific hardware and application platforms.
+Since opkg supports installing packages for multiple architectures on a system,
+platform architectures and real 4-tuple binary architectures should coexist on
+systems without problems.
+
+Distributing package configuration files in binary packages allows package
+maintainers to install configuration files as build dependencies for their
+packages.  Since the configuration files are only needed by maintainers, no
+additional space is wasted on end users' systems.
+
+
+OPKG ARCHITECTURES
+==================
+
+Each application platform will have its own architecture in package archives and
+package manager configurations.  Each such architecture will be an alias for a
+full 4-tuple (CPU microarchitecture, CPU vendor, kernel, and system libraries)
+binary architecture and will refer to the set of application-specific
+configuration packages.
+
+opkg will itself be configured (using its run time configuration file) to use
+any application-specific package archives and to download and install packages
+built for both the application platform architecture and the full 4-tuple binary
+architecture.
+
+
+CONFIGURATION PACKAGES
+======================
+
+For each configurable software package and for each of its supported application
+platforms, there will be exactly one "configuration" binary package.  This
+configuration package will have a name of the form "<pkgname>-config", where
+"<pkgname>" is the name of the configurable source package.  The configuration
+package will install into "/usr/share/config/<pkgname>" any configuration files
+needed by the configurable package at build time or install time.
+
+
+PACKAGE BUILDING
+================
+
+Before build time, the 'build' makefile of a configurable package should copy
+any configuration files needed by the package from
+"/usr/share/config/<pkgname>", where "<pkgname>" is the name of the source
+package, into the temporary build directory structure, wherever the software's
+build system will expect to find it.
+
+Before install time, the 'build' makefile of a configurable package should copy
+any configuration files needed by the package from
+"/usr/share/config/<pkgname>" to the appropriate location in the 'dest'
+directory in the temporary build directory.
+
+Both of these operations might be assisted by a helper program to copy
+configuration files.
--
cgit v0.9.1