Context Navigation

BuildingPackages

Timestamp:: Jun 10, 2013, 5:39:19 PM (11 years ago)
Author:: zooey
Comment:: fixed a couple of typos

Legend:

: Unmodified
: Added
: Removed
: Modified

Obsolete/MovedToTree/PackageManagement/BuildingPackages

-              v20
+              v21
 == Building a Package with the "package" Command ==
 The package file format is in specified in detail in a [wiki:PackageManagement/FileFormat separate document]. This section presents information from the perspective of how to build a package file with the `package` command.
+The package file format is specified in detail in a [wiki:PackageManagement/FileFormat separate document]. This section presents information from the perspective of how to build a package file with the `package` command.
 A hpkg file is an archive file (just like tar or zip files) that additionally contains package meta information in a separate section of the file. When building a hpkg file via the `package` command the meta information must be provided via a `.PackageInfo` file. For convenience the file itself is added to the archive as well and can be extracted later, but it will be ignored by packagefs.
+An hpkg file is an archive file (just like tar or zip files) that additionally contains package meta information in a separate section of the file. When building an hpkg file via the `package` command the meta information must be provided via a `.PackageInfo` file. For convenience, the file itself is added to the archive as well and can be extracted later, but it will be ignored by packagefs.
 The `.PackageInfo` file must be located in the top directory that is archived. A `package` invocation usually looks like that:
 …
  * `copyrights`: A list of copyrights applying to the software contained in this package.
  * `licenses`: A list of names of the licenses applying to the software contained in this package.
  * `urls`: A list of URLs referring to the packaged software's project home page. The list elements can be regular URLs or an email-like named URLs (e.g. "Project Foo <!http://foo.example.com>").
+ * `urls`: A list of URLs referring to the packaged software's project home page. The list elements can be regular URLs or email-like named URLs (e.g. "Project Foo <!http://foo.example.com>").
  * `source-urls`: A list of URLs referring to the packaged software's source code or build instructions. Elements have the same format as those of `urls`.
  * `flags`: A list of boolean flags applying to the package. Can contain any of the following:
 …
 The meaning of the major, minor, and micro version parts is vendor specific. A typical, but not universal (!), convention is to increment the major version when breaking binary compatibility (i.e. version a.d.e is backwards compatible to version a.b.c for all b.c <= d.e), to increment the minor version when adding new features (in a binary compatible way), and to increment the micro version for bug fix releases. There are, however, projects that use different conventions which don't imply that e.g. version 1.4 is backwards compatible with version 1.2. Which convention is used is important for the packager to know, as it is required for a correct declaration of the compatibility versions for the provided resolvables. The compatibility version specifies the oldest version the provided resolvable is backwards compatible with, thus implying the version range requested by a dependent package the resolvable can satisfy. When following the aforementioned convention a resolvable of version 2.4.3 should have compatibility version 2 (or, semantically virtually identical, 2.0.0). Not following the convention 2.4 may be correct instead. If no compatibility version is specified, the resolvable can only satisfy dependency constraints with an exactly matching version.
 The pre-release part of the version string has a special semantics for comparison. Unlike minor and micro its presence makes the version older. E.g. version R1.0~alpha1 is considered to be older than version R1.0. When both version strings have a pre-release part, that part is compared naturally after the micro part (R1.0.1~alpha1 > R1.0 > R1.0~beta1 > R1.0~alpha2).
+The pre-release part of the version string has special semantics for comparison. Unlike minor and micro its presence makes the version older. E.g. version R1.0~alpha1 is considered to be older than version R1.0. When both version strings have a pre-release part, that part is compared naturally after the micro part (R1.0.1~alpha1 > R1.0 > R1.0~beta1 > R1.0~alpha2).
 The revision part of the version string is assigned by the packager (not by the vendor). It allows to uniquely identify updated packages of the same vendor version of a software.
 …
 == Building a Package with "haikuporter" ==
 `haikuporter` is a high level tool for building packages. As input it reads a build recipe file for a certain version of a software (aka port) and produces one or more packages, as declared in the recipe. A recipes specifies package requirements similar to how it is done in an `.PackageInfo` file. When asked to build a port, `haikuporter` resolves the respective dependencies and recursively builds all not-yet-built ports required for the requested port. `haikuporter` itself and a large library of recipe files are hosted at [http://ports.haiku-files.org/ HaikuPorts].
+`haikuporter` is a high level tool for building packages. As input it reads a build recipe file for a certain version of a software (aka port) and produces one or more packages, as declared in the recipe. A recipe specifies package requirements similar to how it is done in a `.PackageInfo` file. When asked to build a port, `haikuporter` resolves the respective dependencies and recursively builds all not-yet-built ports required for the requested port. `haikuporter` itself and a large library of recipe files are hosted at [http://ports.haiku-files.org/ HaikuPorts].
 === The Build Recipe File ===
 For a particular version of a port a recipe file specifies what packages shall be built for that port and it provides all required information for that purpose. A recipe file is name according to the pattern "<portname>-<version>.recipe". The <version> component complies to `version_ref`, though without the revision component. The revision is specified in the recipe itself. It is incremented whenever the recipe itself or a Haiku specific patch for the port changes. A recipe file is a shell script. It is sourced (shell lingo for included) by `haikuporter`. It must set several shell variables and functions that are interpreted and used by `haikuporter`. A set of other variables and functions that can be used in the recipe are defined by `haikuporter` before sourcing it.
+For a particular version of a port a recipe file specifies what packages shall be built for that port and it provides all required information for that purpose. A recipe file is named according to the pattern "<portname>-<version>.recipe". The <version> component complies to `version_ref`, though without the revision component. The revision is specified in the recipe itself. It is incremented whenever the recipe itself or a Haiku specific patch for the port changes. A recipe file is a shell script. It is sourced (shell lingo for included) by `haikuporter`. It must set several shell variables and functions that are interpreted and used by `haikuporter`. A set of other variables and functions that can be used in the recipe is defined by `haikuporter` before sourcing it.