Examples

Here are some examples of files used by UPE:

Note

The examples assume a Linux computer with default settings

See also

[source]/examples/ also contains these examples.

config.ini — Main configuration file

(Comments start with ;)

[packages]
database = /etc/upe/pkgdb.json
; Where the package database is located.

[remote]
allowremote = true
; Whether remote repositories are allowed
repositories = /etc/upe/repositories.ini
; Where te repository list is.

repositories.ini — Repository list

(Comments start with ;)

[DEFAULT]
; This section defines the default settings
port = 8016
; Port to connect

[repository]
url = http://www.example.com/repo

manifest.yaml — Package manifest

(Comments start with #)

%YAML 1.2  # YAML version to be used
---  # Manifest starts here
authors:
  Author 1: Main developer
  Author 2: Developer & Packager
# Authors aren't used outside the manifest.
package: foo
# Package codename, used as the package name.
pkgname: Foo
# 'Official' package name.
version: 0
# Major version (integrer).
release: 1.0
# Minor version.Release (float/real)
# If it hasn't release, consider it 0.
codeame: oof
# Release codename or nickname. Usually, it hasn't, so write 'null'.
pkgrel: 1
# Package release
deps: [hello, bar, baz]
# Package dependencies
buildd: []
# Build dependencies (it hasn't)
optd:
  # Optional dependencies
  package1: Feature
  # When showing optional dependencies, 'package1' will be shown as required for 'Feature'.
  package2: null
  # When showing optd, 'package2' will be shown as required (but users may ask why?)
# In case there aren't optd, write (without the #):
# optd: null
arch: [all]
# Architectures where the package can be run.
license: gpl
# License
tags:
  version:
    alpha: true
    # Whether is in alpha phase.
    beta: false
    unstable: false
  lts: true
  # Long-Term Support?
  binary: false
  # Binary package?
  commercial: false
  # Commercial (you have to pay)?
...  # End of manifest

manifest.json — Compiled package manifest

Note

Actually, a JSON file isn’t a compiled file (in fact, you can’t compile a YAML document), but is easier to read by end-users – the json module is included with Python, but yaml doesn’t.

(JSON hasn’t got comments, but it’s the same than on the YAML file).

Tip

Usually, the JSON file will be only a one line (

{"deps": ["hello", "bar", "baz"], "arch": ["all"], "pkgrel": 1, "tags": {"binary": false, "version": {"beta": false, "unstable": false, "alpha": true}, "commercial": false, "lts": true}, "license": "gpl", "buildd": [], "authors": {"Author 2": "Developer & Packager", "Author 1": "Main developer"}, "optd": {"package2": null, "package1": "Feature"}, "release": 1.0, "pkgname": "Foo", "codeame": "oof", "package": "foo", "version": 0}

), but it has been separed and indented to be more readable.

{
  "arch": [
    "all"
  ],
  "authors": {
    "Author 1": "Main developer",
    "Author 2": "Developer & Packager"
  },
  "buildd": [],
  "codename": "oof",
  "deps": [
    "hello",
    "bar",
    "baz"
  ],
  "license": "gpl",
  "optd": {
    "package1": "Feature",
    "package2": null
  },
  "package": "foo",
  "version": 0,
  "pkgname": "Foo",
  "pkgrel": 1,
  "release": 1.0,
  "tags": {
    "binary": false,
    "commercial": false,
    "lts": true,
    "version": {
      "alpha": true,
      "beta": false,
      "unstable": false
    }
  }
}

Hint

As you can see, the YAML order isn’t preserved