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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
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 "<pkgname>-config", where "<pkgname>" is the name of the
configurable source package. The application platform-specific configuration
package will have a name of the form "<pkgname>-config-<appname>", where
"<appname>" is the name of the application platform architecture. The
application platform-specific configuration package will install into
"/usr/share/config/<appname>/<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.
|
