Difference between revisions of "Platform Team/Guide/Sweets Packaging"

From Sugar Labs
Jump to navigation Jump to search
m
Line 153: Line 153:
 
* [http://0install.net/interface-spec.html Feed file format specification]
 
* [http://0install.net/interface-spec.html Feed file format specification]
 
* [http://0install.net/0compile.html 0compile] [http://0install.net/0compile-dev.html guide]
 
* [http://0install.net/0compile.html 0compile] [http://0install.net/0compile-dev.html guide]
 +
 +
== The workflow of regular Sugar doer will look like: ==
 +
 +
# Having a directory with Sugar project to develop.
 +
#* Directory should be placed to one of default paths.
 +
#* The only important element is a [[Platform Team/Sugar_Doers_Kit/Implementation#Recipes|recipe file]], i.e., an analog of {{Code|activity.info}} file for activities.
 +
# To make it useful, just run it.
 +
#* For activities, just click on activity icon in Sugar Shell.
 +
#* Otherwise, run application using its unique Web url.
 +
# Everything which is related to the process of project running, will be handled automatically.
 +
#* There is always a way to fallback to the particular running step.
 +
#* If project has dependencies, they will be installed or passed though the same running procedure (for under development dependencies).
 +
#* If project needs to be build, it will happen automatically (including installing buildtime dependencies).
 +
# Make Sugar project accessible for others.
 +
#* Only one command call or one click in Sugar Shell is needed.
 +
#* The only requirement, being registered in the system (particular implementations might be different, from [https://cas.sugarlabs.org/ Sugar Labs Central Login] to local school server).
 +
#* Anyone can run recent version of your project just be mentioning its Web url.
 +
# Sharing information about Sugar project.
 +
#* Information about newly released project might be automatically published on [[Activity Library]].
 +
 
-->
 
-->

Revision as of 22:36, 3 September 2011

Pencil.png NOTICE:  This page is a draft in active flux...
Please contribute to these contents and discuss issues on the discussion page.


Writing recipe files

See also recipe specification.

Package names

Within recipe files, Zero packages might be identified by several methods:

  • current package (instead of a direct slug value, to make the recipe file more robust, move the slug option to the [DEFAULT] section and use %(slug)s interpolation),
<current-slug>[/<sub-package>]
  • other packages from Bazaar that are accessible in the current project,
<other-package-slug>[/<sub-package>]
  • direct 0install link.
<0install-feed-url>

At the end, all links will be transfered to 0install feed urls. The final 0install url will be in the following format:

http://sweets.sugarlabs.org/<Bazaar-project>/<slug>

Versioning

The versioning scheme for Zero packages can be arbitrary, since the version recipe option supports 0install version format. But in some cases, e.g., libraries, stricter versioning could be useful. In that case, the age recipe option should be used.

The recipe 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, and since packages may at any time be rebuilt from sources and multiple library versions may be installed (thanks to 0install).

Using the age option is simple, on every API breakage for the library package, increment the age value. The final package version will be:

<age-option>.<version-option>

Glob patterns

A pattern could be of two types:

  • doesn't contain / or ** substrings, will be applied only to file names
  • contains / or ** substring, will be applied to the full file path (relative to the root), thus could affect several directory levels

Only these pattern symbols are allowed:

  • * matches everything, except directory separator
  • ? matches any single character, except directory separator
  • ** matches everything, including directory separator

Pitfalls

Devel packages

It is common practice in binary-based GNU/Linux distributions to use satellite devel packages to collect various build-time files like C headers or pkg-config files. In the 0install environment, this doesn't work, because every package is stored in a separate directory hierarchy, e.g., *.so symlinks, from devel package, will point to nothing, since all *.so.* files from the library package live in a separate directory.

Keep all build-time files in the runtime package.