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, there will be exactly one virtual "configuration" binary package. For each configurable software package and for each of its supported application platforms, there will be exactly one real "configuration" binary package that provides the configurable software package's virtual configuration package. The virtual configuration package will have a name of the form "-config", where "" is the name of the configurable source package. The application platform-specific configuration package will have a name of the form "-config-", where "" is the name of the application platform architecture. The application platform-specific configuration package will install into "/usr/share/config//" 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/", where "" 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/" 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.