summaryrefslogtreecommitdiffstats
path: root/source-package-format-1.0.txt
blob: 25c546e1fa6aebffb428f8af1feff7f3dace5478 (plain)
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
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
ABOUT THIS DOCUMENT
===================

This document describes version 1.0 of the format for software source packages.


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.

TODO
----

  - Decide on build system format (shell scripts or make files).
  - Determine how split packages (e.g. *-dev, *-dbg, libgcc, and g++) will be
    built.


BACKGROUND
==========

A source package consists of software source code, a build system, and package
metadata.  From it is built one or more binary packages, which can be installed
into an operating system.


RATIONALE
=========

This source package format is modeled after the package format of the OpenBricks
Embedded Linux Framework.  However, this format more natively supports the
building of multiple binary packages from one source package.  Additionally,
source packages in this format are intended to be maintained independently (like
Debian packages are) rather than in one monolithic software repository (such as
that of OpenBricks).  In this and other respects, this format draws inspiration
from Debian's source package formats.


DIRECTORY STRUCTURE
===================

PROPOSAL 1
----------

This structure easily supports building multiple independent binary packages
from one source package but does not support building split binary packages.

<pkgname>_<pkgver>-<pkgrev>/
 +- <binpkg>.pkg/
 |   +- build
 |   |    A script to build the binary package.
 |   +- control
 |   |    Metadata about the binary package.
 |   +- install
 |   |    A script to install the binary package.
 |   +- postinst
 |   +- postrm
 |   +- preinst
 |   \- prerm
 +- control
 |    Metadata about the source package.
 +- format
 |    A magic file to identify the source format version.  Should simply contain
 |    the string "1.0".
 +- patches/
 |    Patches to be applied to package sources before building.
 +- <pkgname>_<pkgver>.<ext>
 |    Upstream source archive (for non-native packages).
 \- src/
      Package sources (for native packages).

'build' in the binary package directory might be changed to a dpkg-style make
file with targets for building and installing.

PROPOSAL 2
----------

This structure supports building split binary packages but does not easily
support building multiple independent binary packages from one source package.

Note that this directory structure is very functionally similar to that of
Debian's source package formats.

<pkgname>_<pkgver>-<pkgrev>/
 +- <binpkg>.install
 |    A list of patterns to match files to be installed in a binary package.
 +- <binpkg>.postinst
 +- <binpkg>.postrm
 +- <binpkg>.preinst
 +- <binpkg>.prerm
 +- build
 |    A script to build the binary package(s).
 +- control
 |    Metadata about the source and binary packages.
 +- format
 |    A magic file to identify the source format version.  Should simply contain
 |    the string "1.0".
 +- patches/
 |    Patches to be applied to package sources before building.
 +- <pkgname>_<pkgver>.<ext>
 |    Upstream source archive (for non-native packages).
 \- src/
      Package sources (for native packages).

PROPOSAL 3
----------

This structure is functionally equivalent to that of proposal 2, however, files
and metadata related to binary packages are organized into directories.

<pkgname>_<pkgver>-<pkgrev>/
 +- <binpkg>.pkg/
 |   +- control
 |   |    Metadata about the binary package.
 |   +- install
 |   |    A list of patterns to match files to be installed in the binary package.
 |   +- postinst
 |   +- postrm
 |   +- preinst
 |   \- prerm
 +- build
 |    A script to build the binary package(s).
 +- control
 |    Metadata about the source package.
 +- format
 |    A magic file to identify the source format version.  Should simply contain
 |    the string "1.0".
 +- patches/
 |    Patches to be applied to package sources before building.
 +- <pkgname>_<pkgver>.<ext>
 |    Upstream source archive (for non-native packages).
 \- src/
      Package sources (for native packages).


BINARY PACKAGE METADATA
=======================

Refer to documentation for dpkg and opkg.


SOURCE PACKAGE METADATA
=======================

The format of the source package metadata is to be determined.  It should
resemble either Debian package control file syntax or OpenBricks package
metadata file (shell script) syntax.

Metadata will include information necessary to maintain the source package and
build the binary package(s).  Fields will include the upstream source, build
dependencies, and maintainer contact information.