The package manifest is where all the package info is defining. It’s a YAML file, but when building, it’s converted to a JSON file [1].
It contains the following sections:
Hint
Although the order isn’t really important (it won’t be preserved when converting to JSON), it makes the manifest easier to read.
Is where the author(s) of the package and the developer(s) who made the original software are shown. Note that this section won’t be read and you can omit it, but you shouldn’t do that for official packages. It’s written:
authors:
Author 1: Role
Author 2: Role1 & Role2
Roles are usually developer, packager...
Is the name of the package it must be unique, the valid characters are: az09-_:
package: firefox
Minor version and release of the package (it must be a float or real number):
release: 1.3
Note
If the official version has no release (i.e.: Only major and minor version: 33.1), the release is always 0: 33.1.0, so the code will be:
version: 33
release: 1.0
Code name for the version (if any). It will be shown next to the version number:
# This version shows part the hipotetic manifest for Ubuntu 14.10 (it is imposible to install a distribution with UPE).
package: ubuntu
pkgname: Ubuntu
version: 14
release: 10.0
codename: Utopic Unicorn
pkgrel: 1
If it hasn’t, you can leave it blank, comment it (add a #) or erase it. The following are valid:
codename:
# codename:
# [Nothing]
(Erasing codename is not recommended)
Release of the package. Use this when you changed something, but the upstream hasn’t released a new version. This is very similar to Arch Linux’s pkgrel on PKGBUILDs [2]. It’s an integrer, it starts at 1, and each time you release the package and the version changes, add 1 to it, so the package will be updated. When a new version is released, it starts again from 1.
Dependencies for your package: If it needs Python (for example), you should set deps to:
deps: [python]
If you have more than one dependency (as usually happens), you have to add them comma-separated, as in the UPE’s manifest [3]:
deps: [python, pyyaml]
In the rare case that your program hasn’t dependencies, put an empty []:
deps: []
Build dependencies, those that are only required in build time, usually make (for C/C++ packages) et alii. Follows the same rules than deps.
New in version 0.1.1.
Optional dependencies, those that are required for non-essential functions of the program, but can run without them. It is a list like this:
optd:
package1: <description> # Will show <description> when showing optional dependencies.
package2: null # Won't show anything when showing optional dependencies.
The following optd:
optd:
foo: Adds a function.
bar: null
Will produce the following output:
Optional dependencies:
foo
Adds a function.
bar
Changed in version 0.1.1: Added support for all (both OS and architecture).
Architectures where the package can be run, in the form os-arch according to the following tables:
| OS | os |
|---|---|
| Independent | all |
| Windows | win32 |
| Mac OS X | darwin |
| Linux | linux |
| Architecture | arch |
|---|---|
| Independent | all |
| 64 bits | x86_64 |
| 32 bits | i686 |
| (Older) [4] | i486 |
| i386 |
Note
Use the following code to get your arch (in a Python console):
>>> from platform import machine
>>> print(machine()) # Assuming a 64 bits computer
'x86_64'
>>> print(machine()) # Assuming a (new) 32 bits computer
'i686'
Tip
Use all for both platform and architecture independent (all-all)
New in version 0.1.1.
Examples:
arch: [linux-all] # Only Linux
arch: [linux-x86_64, darwin-all, win32-i686] # Linux (64 bits), Mac (all) and Windows (32 bits)
arch: [all-x86_64] # Only requires a 64 bits processor.
arch: [all] # Universal
License of the software. It’s usually one of the following:
license: gpl # GNU General Public License (generic)
license: gpl2 # GNU GPL v2
license: gpl3 # GNU GPL v3
license: bsd # Berkeley Software Distribution license
license: mit # Massachusetts Institute of Technology license
license: propietary # Propietary software
license: propietary-puel # Personal Use and Evaluation License (Propietary)
Package’s tags. Used to identify packages’ attributes:
tags:
version:
alpha: false
beta: false
unstable: false
lts: false
binary: false
commercial: false
Hint
All the tags have two spaces indentation (to indicate that the are under tags), but the groups have two extra spaces to indicate that they are under another tag (which is the group name), i.e.: alpha, beta and unstable are all under the version group.
It’s better shown in JSON:
{
tags: {
version: {
alpha: false;
beta: false;
unstable: false
};
lts: false;
binary: false;
commercial: false
};
}
Warning
If one group has more than one true tag, the first (using this order) will be considered as valid (the others will be ignored).
Version related tags, those that denote that a package is not yet intended for production:
Version not yet (widely) tested. It may work or it may not. This version is only recommended for brave, lucky or silly people.
Warning
It is dangerous to use alpha versions of essential programs!
Version tested, but not yet ready for production. It should work, but it’s still in testing. You can safely use it, but only for testing.
Caution
It may be dangerous using beta versions of essential programs.
Long-Term Support, a version that has extended support (usually some years).
Indicates that it’s a LTS release. There’s an option which enables the user to select some software to be updated only to a new LTS release (if the current installed version is also LTS, else, it will continue updating normally until you release a LTS version).
Indicates that the package is not built from source, that it uses a prebuilt binary.
See also
Binary packages: A note about building binary packages.
Whether the package is commercial.
See also
Binary packages also has a note about commercial packages.
Hint
Remember that in UPE, commercial is any package that requires the user to pay a license.
Disclaimer
We have used the package firefox for the examples, so we have to include this:
Mozilla® Firefox® is a trademark of Mozilla Foundation
I seldom have heard about trademark problems with Mozilla, but it’s better safe than sorry.
We also used ubuntu, so:
Ubuntu™ is a trademark of Canonical Ltd.
| [1] | The Python Standard Library includes the json module, but not the yaml module, which is provided by PyYAML. |
| [2] | To be honest, UPE is inspired in Arch’s PKGBUILDs and Android’s AndroidManifest.xml. |
| [3] | Actually, UPE hasn’t got a manifest because it can’t update itself (for technical reasons: it would confuse PIP). |
| [4] | While technically you can build for i486 and i386, note that they are also 32 bits processors. |