Changes

== Sub services ==

== Sub services ==

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 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:

   [Service/<sub-name>]

   [<nowiki>Service/<sub-name></nowiki>]

Format of sub sections is identical to ''[Service]'' section. Sub feeds could make sense e.g. for having non-arch data feeds and pure binary feeds (to make per architecture implementations) or to have packaged option for runtime packages (Service) and for *dev* packages (Service/devel).

Format of sub sections is identical to ''[Service]'' section. Sub feeds could make sense e.g. for having non-arch data feeds and pure binary feeds (to make per architecture implementations) or to have packaged option for runtime packages (Service) and for *dev* packages (Service/devel).

There is no need in keeping all ''[Service]'' options in every sub section, in that case it will be more useful to move common options to [DEFAULT] section.

There is no need in keeping all ''[Service]'' options in every sub section, in that case it will be more useful to move common options to ''[DEFAULT]'' section.

Other services can mention sub feeds by format:

Other services can mention sub feeds by format:

  <service-name>/<nowiki><sub-service-name></nowiki>

  <nowiki><service-name>/<sub-service-name></nowiki>

== Recipes ==

== Recipes ==

Slots make sense only for binary services when they could be built against several compatibility ranges of their dependencies and these dependencies could be installed from native packages.

Slots make sense only for binary services when they could be built against several compatibility ranges of their dependencies and these dependencies could be installed from native packages.

Assume that service requires pycairo and source code uses pycairo feature that appeared only in v1.8 but source code can fallback to previous pycairo verisons too. If pycairo can be installed from 0install feeds, there is no need in slots since service can declare "pycairo >= 1.8" dependency and such pycairo will be installed from 0install feeds. But if pycairo could be installed from native packages there are no chances to know in advance what pycairo version will present and service should have two implementations, one for pycairo < 1.8 and one for pycairo >= 1.8. In this case, slots will be useful.

Assume that service requires cairo and source code uses cairo feature that appeared only in v1.8 but source code can fallback to previous cairo verisons too. If cairo can be installed from 0install feeds, there is no need in slots since service can declare "cairo >= 1.8" dependency and such cairo will be installed from 0install feeds. But if cairo could be installed from native packages there are no chances to know in advance what cairo version will present and service should have two implementations, one for cairo < 1.8 and one for cairo >= 1.8. In this case, slots will be useful.

There are two methods to define slots:

There are two methods to define slots:

   slots = <versions-range>

   slots = <versions-range>

In both cases, ''slots'' option will declare compatibility ranges for particular dependency. Only one, closed from both sides, range could be used. For example in pycairo case, it could be:

In both cases, ''slots'' option will declare compatibility ranges for particular dependency. Only one, closed from both sides, range could be used. For example in cairo case, it could be:

   1.0, 1.8, 2.0

   1.0, 1.8, 2.0

1.0 (it could be 0.0 as well) version restrict ranges from the left and 2.0 (most likely v2.0 will be not backwards compatibility with v1.x) from the right, so only two ranges could be chosen, 1.0 >= x < 1.8, 1.8 >= x < 2.0. While building binaries for ''0sugar build'' command, 0sugar will detect what current pycairo version is (service is building/linking against), and will choose proper slot or fail otherwise.

1.0 (it could be 0.0 as well) version restrict ranges from the left and 2.0 (most likely v2.0 will be not backwards compatibility with v1.x) from the right, so only two ranges could be chosen, 1.0 >= x < 1.8, 1.8 >= x < 2.0. While building binaries for ''0sugar build'' command, 0sugar will detect what current cairo version is (service is building/linking against), and will choose proper slot or fail otherwise.

== Predefined options ==

== Predefined options ==