5,705
edits
Changes
Jump to navigation
Jump to search
Line 268:
Line 268: − + − + Line 280:
Line 280: − * ''data'' for non-arch sub packages, − * ''devel'' for sub packages with buildtime data like C header files,
Sugar Network/Recipe Specification (view source)
Revision as of 16:37, 23 July 2010
, 16:37, 23 July 2010→Sub packages
== 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, the 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 if the package contains several logical components, it might have sub packages. In that case, the spec file should contain additional sections (per sub package) 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 packaging additional content, or to separate library and its script language binding.
Other packages can mention sub packages by the format:
Other packages can mention sub packages by the format:
Good practise is using the following names for sub packages:
Good practise is using the following names for sub packages:
* ''python'' for Python binding.
* ''python'' for Python binding.