summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--specs/source-package-format-2.0.txt95
1 files changed, 84 insertions, 11 deletions
diff --git a/specs/source-package-format-2.0.txt b/specs/source-package-format-2.0.txt
index 9840b02..4bf3740 100644
--- a/specs/source-package-format-2.0.txt
+++ b/specs/source-package-format-2.0.txt
@@ -28,7 +28,34 @@ into an operating system.
4. Changes Since Version 1.0
=============================
-TODO
+Following is a summary of differences between versions 1.0 and 2.0 of this
+source package format:
+
+ * The platform configuration file list is now split between two files.
+ `platconf` lists build-time configuration files, and `<binpkg>.pkg/platconf`
+ lists run-time configuration files.
+ - As a result, the platform configuration file lists now have a simpler
+ syntax that does not include the type of configuration file.
+ - It is now easy to determine whether individual binary packages are
+ platform-specific.
+ * Package building can now be configured by a `config` script.
+ - There is now no need for any configuration logic in the `build` makefile.
+ See section 5 for rationale behind this design.
+ - The list of binary packages that can be built from a source package no
+ longer needs to be statically defined.
+ * The source package hierarchy has been clarified to to indicate whether each
+ file is required.
+ - Additionally, certain files are now only required by a certain step in the
+ build process, allowing them to be dynamically generated.
+ * Packages without any sources (such as pure metapackages) are now explicitly
+ allowed.
+ * Maintainer scripts are now explained.
+ * The set of required `build` makefile targets has been changed.
+ - The amount of redundant information in source packages is reduced by not
+ requiring the `build` file to list all binary packages.
+ - The user can choose to build all binary packages, only
+ architecture-independent binary packages, or only architecture-independent
+ binary packages. See section 5 for rationale behind this design.
5. Rationale
@@ -148,7 +175,7 @@ children) shall be removed.
All of the following files are located under what is called a "source package
directory" (`<source-package-directory>` in the tree in section 8). No naming
-requirements are made for this directory. See section 19.1 for a recommended
+requirements are made for this directory. See section 20.1 for a recommended
naming convention for this directory.
10.1. `<binpkg>.pkg/`
@@ -196,6 +223,38 @@ package's `install` file.
See section 14 for the syntax of this file.
+10.5. `<binpkg>.pkg/postinst`
+------------------------------
+
+This file is optional.
+
+This file is a maintainer script to be executed after a binary package is
+unpacked. See section 19 for more information about maintainer scripts.
+
+10.6. `<binpkg>.pkg/postrm`
+----------------------------
+
+This file is optional.
+
+This file is a maintainer script to be executed after a binary package is
+removed. See section 19 for more information about maintainer scripts.
+
+10.7. `<binpkg>.pkg/preinst`
+------------------------------
+
+This file is optional.
+
+This file is a maintainer script to be executed before a binary package is
+unpacked. See section 19 for more information about maintainer scripts.
+
+10.8. `<binpkg>.pkg/prerm`
+------------------------------
+
+This file is optional.
+
+This file is a maintainer script to be executed before a binary package is
+removed. See section 19 for more information about maintainer scripts.
+
10.9. `build`
--------------
@@ -457,10 +516,24 @@ The fields in the binary package metadata are:
description.
-19. Packaging Recommendations
+19. Maintainer Scripts
+=======================
+
+19.1. Maintainer Script Format
+-------------------------------
+
+TODO
+
+19.2. Calling Standard
+-----------------------
+
+TODO
+
+
+20. Packaging Recommendations
==============================
-19.1. Source Package Directory Naming
+20.1. Source Package Directory Naming
--------------------------------------
It is recommended that the name of the source package directory be simply the
@@ -468,7 +541,7 @@ name of the source package. Including the package version number or any part
thereof in the directory name is not recommended, as this number will likely
change over time.
-19.2. `build` File Generation
+20.2. `build` File Generation
------------------------------
For non-trivial packages, it is recommended that the `config` script generates a
@@ -483,7 +556,7 @@ However, it is not specified by POSIX.1 (and therefore cannot be expected to be
supported by all implementations). Furthermore, conditional logic goes beyond
the original design of the `make` utility.
-19.3. Dynamic Binary Package Generation
+20.3. Dynamic Binary Package Generation
----------------------------------------
For certain source packages, the set of binary packages to be built depends on
@@ -494,15 +567,15 @@ generated by the `config` script from template directories named
`<binpkg>.pkg.in/` or similar.
-20. Example Files
+21. Example Files
==================
In the following sections are some example files that might be used for the
-`opkg` source package. They observe the recommendation made in section 19.2 to
+`opkg` source package. They observe the recommendation made in section 20.2 to
make the `config` script generate a `build` makefile from an input `build.in`
file.
-20.1. Example `config` File
+21.1. Example `config` File
----------------------------
Following is an example `config` file:
@@ -520,7 +593,7 @@ Following is an example `config` file:
It detects whether the user intends to cross build the software and generates
appropriate `build` and `host` options for the software's `configure` script.
-20.2. Example `build.in` File
+21.2. Example `build.in` File
------------------------------
Following is an example `build.in` file:
@@ -572,7 +645,7 @@ Additionally, this file relies on the opkhelper utilities to perform tasks
related to the production of binary packages.
-21. Legal Notice
+22. Legal Notice
=================
Copyright (C) 2012 Patrick "P. J." McDermott