Sugar Network/Recipe Specification: Difference between revisions

Line 268:

== Sub packages ==

By default, package ~~has only one feed -~~ ''~~service.xml~~'' ~~which will be composed using~~ ''[~~Service~~]'' ~~section~~. But the service can have ~~additional feeds~~, as well, in that case, ~~''service.info''~~ 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 the service can have sub-packages, as well, in that case, spec file should contain additional sections (per sub feed) in the form:

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

[Package/<nowiki><sub-package></nowiki>]

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

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.

~~There is no need to keep a ''[Service]'' option that would apply to every~~ sub ~~section in every sub section. For that case, it would be easier to move common options to the ''[DEFAULT]'' section.~~

Other packages can mention sub packages by format:

~~Other services can mention~~ sub ~~feeds by format:~~

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

The good practise is using followed names for sub packages:

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

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

== Recipes ==

@@ Line 268: / Line 268: @@
 == Sub packages ==
-By default, package has only one feed - ''service.xml'' which will be composed using ''[Service]'' section. But the service can have additional feeds, as well, in that case, ''service.info'' 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 the service can have sub-packages, as well, in that case, spec file should contain additional sections (per sub feed) in the form:
-   [<nowiki>Service/<sub-name></nowiki>]
+   [Package/<nowiki><sub-package></nowiki>]
-Format of sub sections is identical to ''[Service]'' section. Sub feeds could make sense, e.g., for combining non-arch data feeds and pure binary feeds (to make per-architecture implementations), or to have the packaged option for runtime packages (Service), and for *dev* packages (Service/devel).
+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.
-There is no need to keep a ''[Service]'' option that would apply to every sub section in every sub section.  For that case, it would be easier to move common options to the ''[DEFAULT]'' section.
+Other packages can mention sub packages by format:
-Other services can mention sub feeds by format:
+ <package>/<nowiki><sub-package></nowiki>
- <nowiki><service-name>/<sub-service-name></nowiki>
+The good practise is using followed names for sub packages:
+* ''data'' for non-arch sub packages,
+* ''devel'' for sub packages with buildtime data like C header files.
 == Recipes ==