Sugar Network/Recipe Specification

Spec file sections

The recipe specification file is an analog of scenario files in regular GNU/Linux distributions, like .spec files in RPM. It is the cornerstone of Zero Sugar workflows, everything depends on the recipe file.

For activities, activity.info, an inherited recipe file name, is supported.

[DEFAULT]

Common options. Options from this section will be accessible from all other sections. It may be useful to store options that are common for all sections.

import = <filename> [; ...]

Import another recipe file. Makes sense only within the [DEFAULT] section itself.

[Component]

This is a required section (but see also presets). It describes the main recipe component.

sweet = <identifier>

An identifier of the package. Only lower alphabetic, numeric, "+", "-" or "." symbols are allowed. The sweet identifier should be at least two characters long and start with an alphanumeric character.

sweet is used in several cases:

• in 0isntall feed url - http://sweets.sugarlabs.org/sweet,
• in native package names generated from the recipe.

Important note: The sweet is not intended to be unique. That means that there may be several implementations for the same sweet in the field. They might be different versions of the package from the same developer, or even separate implementations from other developers.

name = <package-name>

Package name, in free form text. (It is equal to the sweet, by default.)

summary = <one-line-description>

Short descriptive line.

description = <multi-line-description>

Long descriptive text. To wrap long text, all lines after the second, should start with spaces. This field is equal to summary by default.

license = <license-name>

Package license. Short license names from Fedora naming scheme are welcome.

homepage = <url>

Packaged project home page.

icon = <icon-file-name>

Path to package icon file starting from the path where the recipe file is located.

category = <category> [; ...]

A classification for the package using values defined by freedesktop.org menu specification.

age = <age-number>

Simple number that will be used as a major number for version, see versioning scheme for details.

version = <version-number>

Current version of the package using 0install version format. If the age option was set, versioning is a bit different.

stability = <stability-level>

Stability level of the current version. Values conform to 0install stability levels and could be:

• insecure
• buggy
• developer
• testing
• stable

requires = <dependency> [(=|>=|<) <version>] [; ...]

List of dependencies that should exist in run-time before using the package. Note that requires from [Build] section are not auto included to this list (e.g., like RPM does).

binding = [prepend|append|replace] <variable-name> [<insert-text-to-prepend-variable-value>] [; ...]

The environment variables 0install should export to the process that uses this package. This makes sense only for multiple-activity-serving dependencies (like libraries), not for the activity itself.

main = <path-to-exec-file>

The relative path of an executable inside the implementation that should be executed by default when the package is run.

exec = <shell-command>

Instead of using an executable program from the main option, sweets can bundle a script to run an arbitrary shell command.

If a package has neither main nor exec, then it cannot be executed. This typically means that the package is for a library.

include = <glob-pattern> [; ...]

Glob pattern for files to include to the package. Path related patterns will be processed starting from %(DISTDIR)s/%(PREFIX)s directory. By default, all files are assumed.

exclude = <glob-pattern> [; ...]

Like include option but for excluding files from the package. In additional, various temporary files will be excluded like .bak or .pyc.

langs = <lang-name> [; ...]
include[<lang-name>] = <glob-pattern> [; ...]
exclude[<lang-name>] = <glob-pattern> [; ...]

A special form of include/exclude options that are intended to create separate, per locale, (sub)packages. If language is mentioned in langs list but doesn't have include[]/exclude[] options, include/exclude will be used (in that case, using special LANG variable makes sense).

arch = <arch>

Makes sense only for binary (sub)packages, and can contain:

• all for noarch (by default)
• any for binaries to use the current architecture

[Buid]

This section is required if package needs additional work to prepare ready-to-use installation. To prepare valid Zero packages, it is important to use predefined constants for options that contain shell commands. All shell commands will be executed from %(SRCDIR)s directory.

NOTE The commands in this section will be executed, not only in the developer's environment, but also in the user's, if a proper binary wasn't found; so move all development-related commands, like autogen.sh, to the [Source] section.

requires = <dependency-name> [(=|>=|<) <version>] [; ...]

What dependencies should be present before building the package from sources. Note that requires from [Component] sections are not auto included to build-time dependencies.

configure = <shell-command>

Shell command to configure sources before building, e.g., invoking the configure script in auto-tools-based projects. If the source code does not require a configuration stage, this option could be omited.

make = <shell-command>

Shell command to make binaries from sources. If the source code does not require a making stage, this option could be omitted.

install = <shell-command>

Shell command to place files that are ready for distribution into the %(DISTDIR)s directory. If install is missing, the entire %(SRCDIR)s (excepting temporary files) will be copied.

implement = <shell-command>

An analog of install command that will be used, if present, instead of install while building the package in the local environment.

[Source]

How to create sources tarball. Options make sense only in the package-developer's environment.

url = <url>

While packaging 3rd-party applications, url to download sources tarball.

patch = <path-to-patch> [patch-level] [; ...]

If source option is used, 3rd-party sources might be patched.

exec = <shell-command>

Execute external program to create sources tarball. Option might be used, e.g., to run make dist command. After executing exec shell command, sweets will pick up newly appeared tarball if it was created in package root directory.

include = <glob-pattern> [; ...]
exclude = <glob-pattern> [; ...]

If neither url nor exec options were used, all files will be bundled and these glob patterns might be used to concretize selection.

requires = <dependency> [(=|>=|<) <version>] [; ...]

The packages that should be present before creating sources tarball. For example, if the exec command generates .c files from .vala, the vala dependency should be mentioned in the requires option.

Presets

Instead of component sections, special sections might be used. These sections extend the standard [Component] options, and might add special meaning to existing ones, see the description for each particular preset.

[Activity]

This preset should be present only for activities (or for applications that could be used also as Activities, e.g., GCompris is a regular application but could be launched in Sugar mode).

Preset uses the same options as [Component] with these additions: j

activity_version = <version>

Option is deprecated, use version instead, but should be still present to not fail in current sugar. It will be useful to use expansion like %(version)s for this option.

bundle_id = <bundle-id>

See activity.info file specification. Option is deprecated, use sweet instead, but should be still present to not fail in current sugar.

icon = <icon-file-name-without-suffix>

Behaviour from activity.info is supported (value should not have ".svg" suffix, and icon file could be found only in activity subdirectory) but deprecated. Regular icon behaviour from [Component] section should be used instead.

exec = <shell-command>

Sugar will pass additional command line arguments to this command.

mime_types = <mime-type> [; ...]

List of mime types supported by the activity. It's used when opening a file from the web or to present to the user a list of activities which can open a certain Journal object.

tags = <tag> [; ...]

Tags give more context in which to group the activity. This is used to allow users to find activities more easily in the Journal, the Home view, etc.

Predefined options

Options defined within [Build] section:

• BUILDDIR where the build happens
• SRCDIR path to directory with sources; for a custom (via 0compile) build, BUILDDIR and SRCDIR are different, while building on OBS, they are the same
• DISTDIR temporary path to place installed files before bundling them
• PREFIX should be used as installation prefix path, e.g., for ./configure --prefix
• CFLAGS default gcc CFLAGS
• CXXFLAGS default gcc CXXFLAGS

In sections that contain langs option:

• LANG current language while building per language implementation

Examples

Python activity

Python-based activity with standard Sugar Platform dependencies.

[Activity]
sweet     = cartoon-builder
name      = Cartoon Builder
summary   = Create your own cell-animation sequences
license   = GPLv2+
homepage  = http://wiki.sugarlabs.org/go/Activities/Cartoon_Builder
icon      = activity/activity-cartoonbuilder.svg
version   = 11.4.9-pre3
stability = testing
exec      = sugar-activity activity.CartoonBuilderActivity

Python library

A python-based library that could be used as is, or as an activity dependency.

[Component]
sweet     = journal
summary   = Hight level library to create your own Journal-like activity
license   = GPLv3+
homepage  = http://wiki.sugarlabs.org/go/Activity_Team/Services/Journal
version   = 1
stability = testing
requires  = toolkit/python
binding   = PYTHONPATH

C-based library

[DEFAULT]
sweet     = polyol
summary   = Intermediate level GObject based libraries for Sugar
description = Polyol is a set of libraries that are written in Vala.
            Libraries are intended to provide high-level C API to basic Sugar
            features including Gtk based user interface. Applications that are
            linked against Polyol, interact with sugar processes
            (like shell, datastore, etc.) via DBus.
license   = LGPLv3+
homepage  = http://wiki.sugarlabs.org/go/Activity_Team/Polyol

age       = 0
version   = 1
stability = testing

depends   = glib; gconf; libgee >= 0.5; gtk+ >= 2.12; pango >= 1.20; librsvg

[Component]
requires  = %(depends)s
binding   = LD_LIBRARY_PATH lib
            PKG_CONFIG_PATH lib/pkgconfig
            VAPIDIR share/vala/vapi
exclude   = python/**
arch      = any

[Component/python]
requires  = %(sweet)s; python; pygtk; pycairo
binding   = PYTHONPATH python
include   = python/**
arch      = any

[Build]
requires  = %(depends)s; pkg-config; cmake; make; gcc-c
configure = cmake -D CMAKE_INSTALL_PREFIX=%(PREFIX)s
                  -D PYTHON_SITEDIR=%(PREFIX)s/python
                  -D COMPONENTS="collab;ds;env;gui;shell;toolkit"
                  -D BINDING=python
                  -D CMAKE_C_FLAGS:STRING="%(CFLAGS)s"
                  %(SRCDIR)s
make      = make
install   = make DESTDIR=%(DISTDIR)s install