8,288
edits
Changes
Jump to navigation
Jump to search
Line 20:
Line 20: − + Line 84:
Line 84: − + Line 233:
Line 233: − + − + Line 249:
Line 249: − + − + Line 259:
Line 259: − Versioning scheme for Zero packages could be arbitrary, since ''version'' spec option supports [http://0install.net/interface-spec.html#id4016582 0install version format]. But in some cases, e.g. libraries, more strict versioning could be useful. In that case ''age'' spec option should be used.+ − Spec option ''age'' is intended to support, mostly, API breakages of library packages. Not ABI, because tracking ABI is not trivial within sugar ecosystem (possible hugeness of code base of different quality)+ − − + Line 284:
Line 283: − + Line 290:
Line 289: − + − The good practise is using followed names for sub packages:+
Sugar Network/Recipe Specification (view source)
Revision as of 13:23, 15 July 2010
, 13:23, 15 July 2010no edit summary
'''repos''' = <name> <feeds-prefix> [downloads-prefix] [; ...]
'''repos''' = <name> <feeds-prefix> [downloads-prefix] [; ...]
Add new or reset existed [[#Package_names|repositories]]. Attribute ''feeds-prefix'' defines Web url prefix for 0install feeds, ''downloads-prefix'' for downloads that feeds contain (equals to ''feeds-prefix'' by default).
Add new or reset existing [[#Package_names|repositories]]. Attribute ''feeds-prefix'' defines a Web url prefix for 0install feeds, ''downloads-prefix'', for downloads that feeds contain (equals to ''feeds-prefix'' by default).
=== Common options ===
=== Common options ===
'''version''' = <version-number>
'''version''' = <version-number>
Current version of the package using [http://0install.net/interface-spec.html#id4016582 0install version format]. If ''age'' option was set, versioning is a bit [[#Versioning|different]].
Current version of the package using [http://0install.net/interface-spec.html#id4016582 0install version format]. If the ''age'' option was set, versioning is a bit [[#Versioning|different]].
'''stability''' = <stability-level>
'''stability''' = <stability-level>
== Package names ==
== Package names ==
Zero Sugar spec file options, like ''requires'', contain links to another packages. Followed link formats are supported:
Zero Sugar spec file options, like ''requires'', contain links to other packages. The following link formats are supported:
* current package to upload to ''target'' repository (instead of direct slug value, to make spec file more robust, move ''slug'' option to [DEFAULT] section and use {{Code|%(slug)s}} interpolation),
* current package to upload to ''target'' repository (instead of a direct slug value, to make the spec file more robust, move the ''slug'' option to the [DEFAULT] section and use {{Code|%(slug)s}} interpolation),
<slug-option-value>[/<nowiki><sub-package></nowiki>]
<slug-option-value>[/<nowiki><sub-package></nowiki>]
At the end, all links will be transfered to 0install feed urls. Repository is just a Web url prefix like http://packages.sugarlabs.org/, the final 0install url will be composed by concatenating repository prefix and package name. Repositories might be:
At the end, all links will be transfered to 0install feed urls. Repository is just a Web url prefix like http://packages.sugarlabs.org/, the final 0install url will be composed by concatenating repository prefix and package name. Repositories might be:
* ''default'' or without mentioning repository name, native GNU/Linux distributions packages from http://namedb.0install.net/;
* ''default'' or without mentioning repository name, the native GNU/Linux distributions packages from http://namedb.0install.net/;
* ''target'', the repository current package will be uploaded to, equals to ''sl'' by default;
* ''target'', the repository the current package will be uploaded to, equals to ''sl'' by default;
* ''sl'', repository hosted by Sugar Labs on http://packages.sugarlabs.org/;
* ''sl'', repository hosted by Sugar Labs on http://packages.sugarlabs.org/;
== Versioning ==
== Versioning ==
The versioning scheme for Zero packages can be arbitrary, since the ''version'' spec option supports [http://0install.net/interface-spec.html#id4016582 0install version format]. But in some cases, e.g., libraries, stricter versioning could be useful. In that case, the ''age'' spec option should be used.
The spec option ''age'' is intended to support, mostly, API breakages of library packages. But not ABI, because tracking an ABI is not trivial within the Sugar ecosystem (due to the enormous potential code base of varying quality) and of little utility, since packages may at any time rebuild from sources and multiple library versions may be installed (thanks to 0install).
and useless since packages could be all time rebuild from sources and multiple library versions could be installed (thanks to 0install).
Using ''age'' option is simple, on every API breakage of library package, increment ''age'' value. Final package version will be:
Using the ''age'' option is simple, on every API breakage for the library package, increment the ''age'' value. Final package version will be:
<age-option>.<version-option>
<age-option>.<version-option>
== Sub packages ==
== Sub packages ==
By default, package is the singular and will be composed using ''[Package]'' or/and ''[Activity]'' sections. But the service can have sub-packages, as well, in that case, spec file should contain additional sections (per sub feed) in the form:
By default, package is the singular and will be composed using ''[Package]'' or/and ''[Activity]'' sections. But the service can have sub-packages, as well, in that case, the spec file should contain additional sections (per sub feed) in the form:
[Package/<nowiki><sub-package></nowiki>]
[Package/<nowiki><sub-package></nowiki>]
Format of sub sections is identical to ''[Package]'' section. Sub packages could make sense, e.g., for combining non-arch data and pure binaries, or to separate runtime and buildtime data.
Format of sub sections is identical to ''[Package]'' section. Sub packages could make sense, e.g., for combining non-arch data and pure binaries, or to separate runtime and buildtime data.
Other packages can mention sub packages by format:
Other packages can mention sub packages by the format:
<package>/<nowiki><sub-package></nowiki>
<package>/<nowiki><sub-package></nowiki>
Good practise is using the following names for sub packages:
* ''data'' for non-arch sub packages,
* ''data'' for non-arch sub packages,