Sugar Network/Recipe Specification: Difference between revisions

Line 268:

== 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>]

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:

Line 280:

Good practise is using the following names for sub packages:

* ''data'' for non-arch sub packages,

* ''devel'' for sub packages with buildtime data like C header files,

* ''python'' for Python binding.

@@ Line 268: / Line 268: @@
 == 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>]
-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:
@@ Line 280: / Line 280: @@
 Good practise is using the following names for sub packages:
-* ''data'' for non-arch sub packages,
-* ''devel'' for sub packages with buildtime data like C header files,
 * ''python'' for Python binding.