5,705
edits
Changes
Jump to navigation
Jump to search
Line 6:
Line 6: − + − + − + − + − import = <filename> [, ...]+ − === [Package] ===+ − This is required section. It describes the main package.+ − '''inherit'''+ − Include options from another section.+ − inherit = <section-name>+ − + − slug = <package-slug>+ − − − name = <package-name>+ − '''summary'''+ − Short descriptive line+ − summary = <one-line-description>+ − − − Long descriptive text. To wrap long text, all lines after second, should start with spaces. This field is equal to ''summary'' by default.+ − description = <multy-line-description>+ − + − License. Short licence names from [http://fedoraproject.org/wiki/Licensing Fedora naming scheme] are welcome.+ − license = <licence-name>+ − '''homepage'''+ − Packaged project home page.+ − homepage = <url>+ − + − + − + − + Line 77:
Line 73: − + − + + + − requires = <dependency> [(>=|<|=) <version>] [, ...]+ − '''slots'''+ − To specify dependency [[#Slots|slots]] on using side:+ − slots[<dependency>] = <dependency-version>, <dependency-verison> [, ...]+ − + − What environment variables, 0install should export to process which uses this package.+ − binding = [prepend|append|replace] <variable-name> [<insert-text-to-prepand-variable-value>] [, ...]+ − '''main'''+ − For applications, path to exec file from root directory that will be executed from 0launch command.+ − main = <relative-path-to-exec-file>+ − − '''exec''' − − Instead of using execution program from ''main'' option, 0sugar can bundle a script to run arbitrary shell command: − − exec = <shell-command> − − − − exec[<script-name>] = <shell-command> − − Last form could be useful when such scripts make sense only in 0install distribution e.g. to pass a path to already bundled command instead of using this command directly: − + − − [[#Glob patterns|Glob pattern]] for files to include to implementations. − − include = <glob-pattern> [, ...] − − By default all files will be included. − '''exclude'''+ − + − exclude = <glob-pattern> [, ...]+ − + + + − + − langs = <lang-name> [, ...]+ − include[<lang-name>] = <glob-pattern> [, ...] − exclude[<lang-name>] = <glob-pattern> [, ...] − If language is mentioned in ''langs'' list but doesn't have ''include[]''/''exclude[]'' options, ''include''/''exclude'' will be used.+ − + − − Specify path from ''DISTDIR'' for ''include''/''exclude'' options. − − prefix = <path> − − '''arch''' − − Makes sense only for binary packages and can contain: + − + − + − − packaged = <distro-name> <package-name> [, ...] − − There are basic distro names + Line 167:
Line 137: − and also exact disto names to be more explicit+ − − * fedora − * suse − * mandriva − * archlinux − * altlinux − − See for more information in [[Documentation Team/Services/Wrap native packages HOWTO|Wrap native packages HOWTO]]. − + − + − + − <service-name> [(>=|<|=) <version>] [, ...]+ − '''exec'''+ − Command how to build binaries.+ − exec = <shell-command>+ − Its value is a shell command, executed inside the build directory $BUILDDIR. It must compile the source in $SRCDIR, putting the final result (ready for distribution) in $DISTDIR. If this command starts to get complicated, you should move it to a script (either inside the main source archive or in a separate dependency) and just set this attribute to the command to run the script.+ − ''NOTE'' This command will be executed not only in service developer environment but also on user side if proper binary wasn't found, so do not use here any development related commands like autogen.sh+ − + − + − + − source = <web-url>+ − '''version'''+ − Optional version of the service, if it's absent, version should be passed via ''--relese'' 0sugar argument or will be parsed from source tarball filename.+ − − version = <version> − − '''requires''' − − What services should present before invoking ''0sugar dist'' command i.e. only in maintainer environment not even while building service from sources on user side. − − requires = <dependency> [(>=|<|=) <version>] [, ...] − − '''patch''' − patch = <path-to-patch> [patch-level] [, ...]+ − − − − Command how to bundle service. − exec = <shell-command>+ − + Line 246:
Line 194: − + − +
Sugar Network/Recipe Specification (view source)
Revision as of 03:50, 2 July 2010
, 03:50, 2 July 2010no edit summary
== 0sugar.info file ==
== 0sugar.info file ==
The {{Code|0sugar.info}} specification file is an analog of scenario files in regular GNU/Linux distributions, like .spec files in RPM.
The 0sugar.info specification file is an analog of scenario files in regular GNU/Linux distributions, like .spec files in RPM. It is corner stone of Zero Sugar workflows, everything is depending on 0sugar.info spec file.
=== [DEFAULT] ===
=== [DEFAULT] ===
Common options. Options from this section will be accessible from all other sections.
Common options. Options from this section will be accessible from all other sections. It could be useful to store options that are common for all sections.
'''import'''
'''import''' = <filename> [, ...]
Import another spec file.
Import another spec file. Makes sense only within [DEFAULT] section itself.
=== Common options ===
Options that are common for all sections except [DEFAULT].
'''inherit''' = <section-name>
Include options from another section.
=== [Package] ===
This is required section (but could be replaced by [Activity]). It describes the main package.
'''slug'''
'''slug''' = <package-slug>
The string used as identifier in cases like 0isntall feed urls or native package names. Only lower alphabetic, numeric, "_", "+" or "-" symbols are allowed.
The string used as identifier in cases like 0isntall feed urls or native package names. Only lower alphabetic, numeric, "_", "+" or "-" symbols are allowed.
'''name''' = <package-name>
'''name'''
Package name in free form, equals to ''slug'' by default.
Package name in free form, equals to ''slug'' by default.
'''summary''' = <one-line-description>
Short descriptive line.
'''description''' = <multi-line-description>
Long descriptive text. To wrap long text, all lines after second, should start with spaces. This field is equal to ''summary'' by default.
'''description'''
'''license''' = <licence-name>
Package license. Short licence names from [http://fedoraproject.org/wiki/Licensing Fedora naming scheme] are welcome.
'''licence'''
'''homepage''' = <url>
Packaged project home page.
'''icon''' = <icon-file-name>
Relative (from Zero Sugar based project) path to icon file.
'''category''' = <category> [, ...]
A classification for the package using values defined by [http://standards.freedesktop.org/menu-spec/latest/apa.html freedesktop.org menu specification].
'''version'''
'''version''' = <version-number>
Current version of package.
Current version of the package using [http://0install.net/interface-spec.html#id4016582 0install version format].
'''stability'''
'''stability''' = <stability-level>
Stability level of current version. Values could be:
Stability level of current version. Values conform to [http://0install.net/interface-spec.html#id4016716 0install stability levels] and could be:
* insecure
* insecure
* buggy
* buggy
* stable
* stable
'''requires'''
'''requires''' = <dependency> [(=|>=|<) <version>] [, ...]
List of dependencies that should exist before using this one. Option accepts also full 0install urls (could be useful to include non 0sugar dependencies).
List of dependencies that should exist before using the package. Dependency names could be:
* name of other package within Zero Sugar
* regular 0install feed url
'''slots'''[<dependency>] = <first-dependency-version> [, ...], <last-dependency-verison>
To specify dependency [[#Slots|slots]]..
'''binding''' = [prepend|append|replace] <variable-name> [<insert-text-to-prepand-variable-value>] [, ...]
What environment variables, 0install should export to process which uses this package. Makes sense only for various activity dependencies (like libraries), not for activity itself.
'''binding'''
'''main''' = <path-to-exec-file>
For applications, relative (from Zero Sugar based project) path to exec file. Doesn't make sense for packages like libraries.
'''exec''' = <shell-command>
Instead of using execution program from ''main'' option, 0sugar can bundle a script to run arbitrary shell command.
'''exec'''[<script-name>] = <shell-command>
Also, 0sugar can bundle arbitrary shell scripts. It could be useful for 0install distribution e.g. to pass a path to already bundled command instead of using this command directly:
Also, 0sugar can bundle arbitrary shell scripts:
binding = replace VALADIR, PATH
binding = replace VALADIR, PATH
exec[valac] = exec "$VALADIR"/bin/valac --vapidir "$VALADIR"/share/vala/vapi "$@"
exec[valac] = exec "$VALADIR"/bin/valac --vapidir "$VALADIR"/share/vala/vapi "$@"
'''include'''
'''include''' = <glob-pattern> [, ...]
[[#Glob patterns|Glob pattern]] for files to include to package. By default, all files are assumed.
[[#Glob patterns|Glob pattern]] for files to exclude from implementations.
'''exclude''' = <glob-pattern> [, ...]
[[#Glob patterns|Glob pattern]] for files to exclude from package. In additional, various files will be excluded like ''.bak'' or ''.pyc''.
'''langs'''
'''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, implementations.
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 [[#Predefined_options|LANG]] variable makes sense).
'''prefix''' = <path>
Could be used in conjunction with ''include''/''exclude'' to specify new root path within directory created by ''install'' command.
'''prefix'''
'''arch''' = <arch>
Makes sense only for binary (sub)packages and can contain:
* ''*'' for noarch (by default)
* ''*'' for noarch (by default)
* ''build'' for binaries to use current architecture
* ''build'' for binaries to use current architecture
'''packaged'''
'''packaged''' = <distro-name> <package-name> [, ...]
If service could be installed from native packaging system, use this option to let 0install know what packages names are on particular GNU/Linux distribution.
If package could be installed from official GNU/Linux distributions repository (i.e. not from packages generated from 0sugar.info spec file on OBS), use this option to let 0install know what packages names are on particular GNU/Linux distribution.
Distribution names could be:
* ''rpm'' for all rpm based distros
* ''rpm'' for all rpm based distros
* ''debian'' for deb based distros
* ''debian'' for deb based distros
* ''ports'' FreeBSD Ports
* ''ports'' FreeBSD Ports
=== [Activity] ===
=== [Buid] ===
=== [Buid] ===
How to build binaries. If service contains binary implementations, this section should present to describe building process.
How to build binaries. If package contains binary implementations, this section should present to describe building process.
'''requires'''
'''requires''' = <dependency-name> [(=|>=|<) <version>] [, ...]
What services should present before building this one from sources.
What packages should present before building this one from sources. Similar to ''requires'' option from ''[Package]''.
'''build''' = <shell-command>
How to build binaries.
Its value is a shell command, executed inside the build directory $BUILDDIR. It must compile the source in $SRCDIR, putting the final result (ready for distribution) in $DISTDIR. If this command starts to get complicated, you should move it to a script (either inside the main source archive or in a separate dependency) and just set this attribute to the command to run the script.
''NOTE'' This command will be executed not only in developer environment but also on user side if proper binary wasn't found, so do not use here any development related commands like autogen.sh
'''install''' = <shell-command>
How to install package.
=== [Maintain] ===
=== [Maintain] ===
Various service maintaining related settings.
Various options that make sense only on package developer side.
'''source'''
'''source''' = <web-url>
Web link to the sources tarball, if parameter is absent, exec from this section will be used to generate tarball
Web link to the sources tarball, if parameter is absent, exec from this section will be used to generate tarball.
'''requires''' = <dependency> [(=|>=|<) <version>] [, ...]
What packages should present before invoking {{Code|0sugar dist}} command i.e. only in maintainer environment not even while building package from sources on user side or on OBS.
'''patch''' = <path-to-patch> [patch-level] [, ...]
Patch downloaded tarball, makes sense only if source parameter exists. Option ''exec'' should present as well to make new tarball.
Patch downloaded tarball, makes sense only if source parameter exists. Option ''exec'' should present as well to make new tarball.
'''exec''' = <shell-command>
'''exec'''
How to bundle package.
Shell command, executed from service root directory. If this command starts to get complicated, you should move it to a script and just set this attribute to the command to run the script. By default 0sugar just bundle entirely service directory excluding temporary files. If source parameter exists in this section, command will be executed within extracted directory of downloaded tarball.
Shell command, executed from package root directory. If this command starts to get complicated, you should move it to a script and just set this attribute to the command to run the script. By default 0sugar just bundle entirely package directory excluding temporary files. If source parameter exists in this section, command will be executed within extracted directory of downloaded tarball.
== Glob patterns ==
== Glob patterns ==
* ''**'' matches everything including directory separator
* ''**'' matches everything including directory separator
== Sub services ==
== Sub packages ==
By default service has only one feed - ''service.xml'' which will be composed using ''[Service]'' section. But service can have additional feeds as well, in that case ''service.info'' should contain additional sections (per sub feed) in form:
By default package has only one feed - ''service.xml'' which will be composed using ''[Service]'' section. But service can have additional feeds as well, in that case ''service.info'' should contain additional sections (per sub feed) in form:
[<nowiki>Service/<sub-name></nowiki>]
[<nowiki>Service/<sub-name></nowiki>]