A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://www.haiku-os.org/docs/develop/packages/BuildingPackages.html below:

Building Packages — Haiku internals documentation

Building Packages

This page provides information regarding the package building process. The first section documents building a package with the low level command package. The second section refers to building packages with the haikuporter tool.

Building a Package with the “package” Command

The package file format is specified in detail in Haiku Package File Format. This section presents information from the perspective of how to build a package file with the package command.

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:

package create -C foo-4.5.26-1 foo-4.5.26-1-x86.hpkg

or (packaging a gcc2 build from within the folder):

cd foo-4.5.26-1
package create ../foo-4.5.26-1-x86_gcc2.hpkg

The argument of the -C option specifies the directory whose contents to archive (by default the current directory), the remaining argument is the path of the package file to be built.

The .PackageInfo

The contents of the .PackageInfo adheres to a restricted driver settings syntax. It consists of name-value pairs, following this simple grammar:

package_info  ::= attribute*
attribute     ::= name value_list
value_list    ::= value | ( "{" value* "}" )
value         ::= value_item+ ( '\n' | ';' )

name can be one of the attribute names defined below. value_item is either an unquoted string not containing any whitespace characters or a string enclosed in quotation marks (" or ') which can contain whitespace and also escaped characters (using \).

The supported attributes are:

Version Strings

Versions strings are used in three contexts: For the package version, for resolvable versions (provides), and in dependency version expressions (requires, supplements, conflicts, freshens). They are structurally identical, with the exception that the former requires a revision component (version), while the latter two don’t (version_ref):

version       ::= major [ "." minor [ "." micro ] ] [ "~" pre_release ] "-" revision
version_ref   ::= major [ "." minor [ "." micro ] ] [ "~" pre_release ] [ "-" revision ]
major         ::= alphanum_underline+
minor         ::= alphanum_underline+
micro         ::= alphanum_underline_dot+
pre_release   ::= alphanum_underline_dot+
revision      ::= positive_non_zero_integer

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 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.

Package File Names

A package file name should have the following form:

file_name     ::= name "-" version "-" architecture ".hpkg"
Example package file 
name                  example
version               42.17-12
architecture          x86_gcc2
summary               "This is an example package file"
description           "Haiku has a very powerful package management system. Really, you should try it!
it even supports muliline strings in package descriptions"
packager              "John Doe <test@example.com>"
vendor                "Haiku Project"
licenses {
      "MIT"
}
copyrights {
      "Copyright (C) 1812-2013 by John Doe <test@example.com>"
}
provides {
      example = 42.17-12
      cmd:example = 3.1
}
requires {
      haiku >= r1~alpha4_pm_hrev46213-1
      lib:libpython2.6 >= 1.0
}
urls {
      "http://example.com/"
}
global-writable-files {
      "settings/example/configurationFile" keep-old
      "settings/example/servers" directory keep-old
}
source-urls {
      "Download <http://example.com/source.zip>"
}
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 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 HaikuPorts. A detailed documentation for haikuporter and the recipe format can also be found there.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3