5,705
edits
Changes
Jump to navigation
Jump to search
Line 82:
Line 82: − − === Slots === − − Slots make sense only for binary services when they could be built against several compatibility ranges for their dependencies and these dependencies could be installed from native packages. − − Assume that a service requires cairo, and that the source code uses a cairo feature that appeared only in v1.8, but the source code can fallback to previous cairo versions, as well. If cairo can be installed from 0install feeds, then there is no need for slots, since the service can declared as a "cairo >= 1.8" dependency, and so cairo will be installed from 0install feeds. But if cairo could be installed from native packages, there is no way to know in advance which cairo version will be present, and the service should have two implementations, one for cairo < 1.8 and one for cairo >= 1.8. In this case, slots will be useful. − − To declare slots for a package dependency, ''slots'' and appropriate ''requires'' options should be placed in the ''[Service]'' section that uses the dependency: − − requires = <dependency> − slots[<dependency>] = <versions-range> − − Option ''slots'' will declare compatibility ranges for a particular dependency. Only one, closed from both sides, range can be used. For example, in the cairo case, it could be: − − 1.0, 1.8, 2.0 − − The 1.0 (it could be 0.0 as well) restricts the version range from the left and the 2.0 (most likely v2.0 will not be backwards compatible with v1.x) from the right; so only two ranges can be chosen, 1.0 >= x < 1.8, 1.8 >= x < 2.0. While building binaries for the ''0sugar build'' command, 0sugar will detect what the current cairo version is (the service that it is building/linking against), and will choose the proper slot or fail, otherwise.
Platform Team/Guide/Sweets Packaging (view source)
Revision as of 08:55, 4 August 2010
, 08:55, 4 August 2010→Slots
The same component could be a part of different recipes. In that case, the different package implementations will contain the same recipe component tarball.
The same component could be a part of different recipes. In that case, the different package implementations will contain the same recipe component tarball.
== Pitfalls ==
== Pitfalls ==