* [http://www.packagekit.org/ PackageKit] to install software from native packaging systems.
* [http://www.packagekit.org/ PackageKit] to install software from native packaging systems.
* [http://download.sugarlabs.org/ Sugar Labs]'s resources to host various files.
* [http://download.sugarlabs.org/ Sugar Labs]'s resources to host various files.
+
+
=== Identification ===
+
+
Every Zero Sugar package is identified by a Web url like [http://services.sugarlabs.org/gcompris GCompris]. The file, url points to, is regular 0install feed (in other words, 0install package) that contains metadata about package itself and all its implementations.
+
+
Implementations are Web links to tarballs. Packages are split into implementations to:
+
* let user launch not only last version e.g. package can contain implementations for several branches or/and stabilities,
+
* split binary implementations per OS and platform,
+
* split implementations per language.
+
+
Zero Sugar natively supports ''forks'' (better name?) that are similar to [http://en.wikipedia.org/wiki/Fork_%28software_development%29 regular] forks in FOSS but could be just results of doers' experiments i.e. without intension to push changes to an upstream. Forks are regular Zero packages and identified by unique Web url but linked to an upstream package (by mentioning upstream url in [http://0install.net/interface-spec.html#id4015759 feed-for] metadata field). So, having an upstream activity http://go.sugarlabs.org/Record, http://A.doer.org/My_Record from doer A and http://B.doer.org/My_Record from doer B, user C will have http://go.sugarlabs.org/Record implementations from three sources.