School Network/Open Build Service: Difference between revisions

Line 64:

== Usage ==

There are several OBS usage workflows.

=== Sweets ===

[[Platform_Team/Sweets|Sweets]] is using OBS as a place to host sources and, if there is need, build binaries. There are two ways to interact with OBS:

* Console based client, {{Code|sweets}}, for uploading new releases;

* Application to manage already released versions, it is possible to use packages.sugarlabs.org for that but it is too overfeatured and need to be replaced by more appropriate option.

The result will be reused via Zero Install.

=== Sweet packages ===

After beeing released, sweets might be formed to native packages repositories. For that case:

* Create new project;

* Add new repositories packages need to be build for, they should be directly or indirectly inherited from the {{Code|base}} project;

* Go to OBS package that represent a sweet you need to build native packages for, e.g., [https://packages.sugarlabs.org/package/show?package=sugar&project=sdk sugar];

* Click ''Link sweet package'' link to add it to your project.

The result will be regular OBS repositories with native packages. The only difference is that after installing on target systems, the content of these packages will be placed to {{Code|/opt}} directory instead of regular {{Code|/usr}}. The reason is that sweets are not indented to be placed directly to the {{Code|/usr}} and there might be file name collisions with existed files.

=== Recipe based packages ===

~~=== Aliases ===~~

These are regular OBS packages except that instead of regular spec files, e.g., RPM {{Code|.spec}}, they might be build basing on [[Platform_Team/Recipe_Specification#.5BPackage.5D|sweets.recipe}} files. It is a kind of meta packaging but restricted by design. In comparing with sweet packages, these packages will be placed to {{Code|/usr}}.

=== Regular packages ===

It is exactly how OBS is originally designed to work.

== Policy ==

@@ Line 64: / Line 64: @@
 == Usage ==
+There are several OBS usage workflows.
 === Sweets ===
+[[Platform_Team/Sweets|Sweets]] is using OBS as a place to host sources and, if there is need, build binaries. There are two ways to interact with OBS:
+* Console based client, {{Code|sweets}}, for uploading new releases;
+* Application to manage already released versions, it is possible to use packages.sugarlabs.org for that but it is too overfeatured and need to be replaced by more appropriate option.
+The result will be reused via Zero Install.
 === Sweet packages ===
+After beeing released, sweets might be formed to native packages repositories. For that case:
+* Create new project;
+* Add new repositories packages need to be build for, they should be directly or indirectly inherited from the {{Code|base}} project;
+* Go to OBS package that represent a sweet you need to build native packages for, e.g., [https://packages.sugarlabs.org/package/show?package=sugar&project=sdk sugar];
+* Click ''Link sweet package'' link to add it to your project.
+The result will be regular OBS repositories with native packages. The only difference is that after installing on target systems, the content of these packages will be placed to {{Code|/opt}} directory instead of regular {{Code|/usr}}. The reason is that sweets are not indented to be placed directly to the {{Code|/usr}} and there might be file name collisions with existed files.
 === Recipe based packages ===
-=== Aliases ===
+These are regular OBS packages except that instead of regular spec files, e.g., RPM {{Code|.spec}}, they might be build basing on [[Platform_Team/Recipe_Specification#.5BPackage.5D|sweets.recipe}} files. It is a kind of meta packaging but restricted by design. In comparing with sweet packages, these packages will be placed to {{Code|/usr}}.
 === Regular packages ===
+It is exactly how OBS is originally designed to work.
 == Policy ==