All packages consist of a single build file, which provides all of the required metadata for the package manager, plus the build steps involved to produce a package. This follows the YAML specification.
As can be seen in the example below, the file is organised into a key->value hierarchy. Some values may be required to be in a list format, whereas most are simple strings. The build step sections are all considered optional, however if you do not
perform *any* steps, then no package is generated. Each of these keys contains content that will be placed within a script and executed within a controlled environment to perform the package build. To all intents and purposes, they are bash scripts
Not all fields in `package.yml` are mandatory, but a small selection are. They are listed below. Note that `string(s)` indicates that it is possible to use a `list` of strings, or one single `string`
`dict` refers to a `key : value` split in YAML, and `dict(s)` refers to a list of `dict`s
**name** | `string` | The name of the package. This is also used as the base of all sub-package names. Unless unavoidable, this should match the upstream name
**version** | `string` | The version of the currently packaged software. This is taken from the tarball in most cases.
**release** | `integer` | Specifies the current release number. Updates in the package number are based on this `release` number, *not* the `version` number. As such, to release an update to users, this number must be incremented by one.
**license** | `string(s)` | Valid upstream license(s). Try to ensure these use [SPDX identifiers](http://spdx.org/licenses/).
**source** | `dict(s)` | Upstream source location (i.e. tarball), with the valid `sha256sum` as a value
**component** | `string` | Component / group of packages this package belongs to. Check available components via `eopkg lc`
**summary** | `string` | Brief package summary, or display name
**description** | `string` | More extensive description of the software, usually taken from the vendor website
**clang** | `bool` | Set to `no` if this package cannot be built with Clang
**extract** | `bool` | Set to `no` to disable automatic source extraction.
**autodep** | `bool` | Set to `no` to disable automatic binary dependency resolution at build time
**emul32** | `bool` | Set to `yes` to enable an `-m32` build (32-bit libs)
**libsplit** | `bool` | Set to `no` to disable splitting of libraries into `devel` sub-packages
**rundeps** | `dict(s)` | Specify further runtime dependencies for the packages
**replaces** | `dict(s)` | Replace one package with another, used when renaming or deprecating packages for clean upgrade paths
**patterns** | `dict(s)` | Allows fine grained control over file placement within the package or sub-packages. Useful for packages that are development only (i.e. `/usr/bin` files)
Note that each step in itself is optional, however all can be used. The value of each of these keys is merged into a build script that is executed for each stage of the build.
Step Name | Description
---- | ----
**setup** | Performed after the source extraction. This is the correct place to perform any `configure` routine, or to `patch` the sources.
**build** | Use this step to run the build portion, i.e. `make`
**install** | This is where you should install the files into the final packaging directory, i.e. `make install`
**check** | There is where tests / checking should occur, i.e. `make check`
To further assist in packaging, a number of macros are available. These are simply shorthand ways to perform a normal build operation. They also ensure that the resulting package is consistent. These macros are only available in our build steps, as
they are substituted within the script before execution.
Macros are prefixed with `%`, and are substituted before your script is executed. Macros ending with `%` are used to provide directory names or build values, to the script.
``` bash
# Run the configure macro with the given arguments
**%CONFOPTS%** | Flags / options for configuration, such as `--prefix=/usr`. [Full List.](https://github.com/solus-project/ypkg/blob/master/ypkg2/rc.yml#L117)
The `package.yml` file uses native YAML types, however for the sake of clarity an explanation of how they are used within the context of `ypkg` is provided below.
Known as an associative array, this is key to value mapping. These are separated by a colon (`:`), the token on the left is taken to be a key, and the token on the right is the value.
`SomeKey: Some Value`
Note that each `ypkg key` in the YAML file is actually a dict.
This is a combination of the `list` type, the `dict` type and some assumptions. We primarily make use of this to express advanced information within the package. These permit you to provide no key, and a value only.
In this instance, the key is assumed to be the package `name`:
