Move source package format to 'specs' directory.

1 files changed, 0 insertions, 183 deletions

diff --git a/source-package-format-1.0.txt b/source-package-format-1.0.txt
deleted file mode 100644
index aa12f98..0000000
--- a/source-package-format-1.0.txt
+++ /dev/null
@@ -1,183 +0,0 @@
-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
-----
-  * Finish describing binary package control fields.
-  * Describe the control file format.
-
-
-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 directory structure proposal has been declared defunct and removed from
-this document.
-
-PROPOSAL 2
-----------
-
-In this structure, all source and binary packaging files are kept in the same
-directory.
-
-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 makefile with target rules 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 makefile with target rules 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).
-
-
-CONTROL FILE FORMAT
-===================
-
-See documentation on Debian packaging.
-
-
-BINARY PACKAGE METADATA
-=======================
-
-The fields in the binary package metadata are:
-  * Package (required)
-    The name of the binary package.  Binary package names may only consist of
-    lowercase Latin letters, digits, plus and minus signs, and periods.  Names
-    must be at least two characters long and must start with either a letter or
-    a digit.
-  * Architecture (required)
-    The names of the architectures for which this package is built.  The list of
-    names may consist of values selected from the following:
-      - A four-tuple binary architecture name to specify that the package can be
-        built for the binary architecture and any application platform.
-      - An application platform architecture name to specify that the package
-        can be built for the application platform and its associated binary
-        architecture.
-    Alternatively, the list may consist solely of one of the following values:
-      - The string "all" to specify that the package can be built on any binary
-        architecture and any application platform and can then be installed on
-        binary architectures and/or application platforms other than those on
-        which it is built.
-      - The string "any" to specify that the package cen be built for any binary
-        architecture and any application platform.
-  * Essential (optional)
-    A flag to indicate whether the package is essential for the functioning of a
-    system on which it is installed.  If this field is set to "yes", opkg will
-    refuse to remove the package except when upgrading it.  If this field is set
-    to any other value or is omitted, the package may be removed by a user.
-  * Depends (optional)
-  * Recommends (optional)
-  * Suggests (optional)
-  * Pre-Depends (optional)
-  * Conflicts (optional)
-  * Provides (optional)
-  * Replaces (optional)
-  * Description (required)
-
-
-SOURCE PACKAGE METADATA
-=======================
-
-The fields in the source package metadata are:
-  * Source (required)
-    The name of the source package.  Source package names may only consist of
-    lowercase Latin letters, digits, plus and minus signs, and periods.  Names
-    must be at least two characters long and must start with either a letter or
-    a digit.
-  * Maintainer (required)
-    The name and e-mail address of the package maintainer.  This field must
-    follow the syntax of the "mailbox" symbol in RFC 822 section 6.1.
-  * Build-Depends (optional)
-    A list of packages that must be installed before the package can be built.
-  * Homepage
-    The URL of the Web site for the package.  Accessible at this site should be
-    origin source code and documentation and/or information.  Though the
-    information in this field is machine-usable, the URL must not be surrounded
-    by angle brackets or any other characters.