School Network/Open Build Service: Difference between revisions

Line 62:

== Usage ==

~~There are several~~ OBS ~~usage workflows~~.

On top of original OBS behavior, Sugar Labs patch brings the following new features.

=== ~~Sweets~~ ===

=== Distribution agnostic packages ===

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

Instead of using spec files for every distribution packages should be built against, it is possible to use special spec file that will be used as-is an all platforms Sugar Labs OBS supports.

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

To create such distro-agnostic packages:

* An application to manage already released versions. It is possible to use packages~~.sugarlabs.org for that, but it is too overfeatured and needs to be replaced by a more appropriate alternative.~~

~~The result will be reused via Zero Install~~.

* upload {{Code|sweets.recipe}} file in [[Platform_Team/Recipe_Specification|special notation]] to OBS package;

* upload {{Code|.tar.gz}} sources with filename composed using {{Code|sweets.recipe}} fields:

~~=== Sweet packages ===~~

<implement>-<version>.tar.gz

After ~~being released~~, ~~sweets might be formed into native~~ package repositories. ~~For that use case:~~

After that, OBS will star building submitted package on all attached OBS repositories.

* Create a new project;

=== Resolve packages and dependencies ===

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

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

* Click the ''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 installation on target systems, the content of these packages will~~ be ~~placed in the {{Code|/opt}} directory instead of the regular {{Code|/usr}}. The reason for this is that sweets are not intended~~ to ~~be placed directly in the {{Code|/usr}} directory as there might be file name collisions with existing system files in the {{Code|/usr}} directory~~.

There is new API command that might be used to resolve package names and package dependencies on particular OBS platform.

=== ~~Recipe based packages =~~==

GET '''/resolve'''?project=PROJECT&repository=REPOSITORY&arch=ARCH&package=PACKAGE[&withdeps][&exclude=PACKAGE]

These are regular OBS packages except that instead of regular spec files, e.g., RPM {{Code|.spec}}, they might be built based on [[Platform_Team/Recipe_Specification#.5BPackage.5D|sweets.recipe]] files. It is a kind of meta packaging, but restricted by design. As opposed to sweet packages, these packages will be placed in the {{Code|/usr}} directory.

Where:

~~=== Regular packages ===~~

* {{Code|PROJECT}}, {{Code|REPOSITORY}}, {{Code|ARCH}} and {{Code|PACKAGE}}<br>identification of particular OBS package;

* {{Code|withdeps}}<br>include dependencies graph of the {{Code|PACKAGE}};

* {{Code|exclude}}<br>restrict dependency graph from bottom side.

~~Regular~~ packages ~~is exactly how~~ OBS ~~was originally designed to work~~.

For example,

https://obs.sugarlabs.org/resolve?project=OLPC:11.3.1&repository=Fedora-14&arch=i586&package=pygame&withdeps&exclude=sugar

Will output:

</resolve>

Note that {{Code|url}} attributes might be invalid if corresponding packages were used to building on OBS. So, keep special OBS projects, only for resolving purpose, like {{Code|OLPC}}.

== Policy ==

@@ Line 62: / Line 62: @@
 == Usage ==
-There are several OBS usage workflows.
+On top of original OBS behavior, Sugar Labs patch brings the following new features.
-=== Sweets ===
+=== Distribution agnostic packages ===
-[[Platform_Team/Sweets|Sweets]] is using OBS as a place to host sources and, if there is a need, to build binaries. There are two ways to interact with OBS:
+Instead of using spec files for every distribution packages should be built against, it is possible to use special spec file that will be used as-is an all platforms Sugar Labs OBS supports.
-* Console based client, {{Code|sweets}}, for uploading new releases;
+To create such distro-agnostic packages:
-* An application to manage already released versions. It is possible to use packages.sugarlabs.org for that, but it is too overfeatured and needs to be replaced by a more appropriate alternative.
-The result will be reused via Zero Install.
+* upload {{Code|sweets.recipe}} file in [[Platform_Team/Recipe_Specification|special notation]] to OBS package;
+* upload {{Code|.tar.gz}} sources with filename composed using {{Code|sweets.recipe}} fields:
-=== Sweet packages ===
+ <implement>-<version>.tar.gz
-After being released, sweets might be formed into native package repositories. For that use case:
+After that, OBS will star building submitted package on all attached OBS repositories.
-* Create a new project;
+=== Resolve packages and dependencies ===
-* Add repositories that packages need to be built for, they should be directly or indirectly inherited from the {{Code|base}} project;
-* Go to the OBS package that represents a sweet you need to build native packages for, e.g., [https://packages.sugarlabs.org/package/show?package=sugar&project=sdk sugar];
-* Click the ''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 installation on target systems, the content of these packages will be placed in the {{Code|/opt}} directory instead of the regular {{Code|/usr}}. The reason for this is that sweets are not intended to be placed directly in the {{Code|/usr}} directory as there might be file name collisions with existing system files in the {{Code|/usr}} directory.
+There is new API command that might be used to resolve package names and package dependencies on particular OBS platform.
-=== Recipe based packages ===
+ GET '''/resolve'''?project=PROJECT&repository=REPOSITORY&arch=ARCH&package=PACKAGE[&withdeps][&exclude=PACKAGE]
-These are regular OBS packages except that instead of regular spec files, e.g., RPM {{Code|.spec}}, they might be built based on [[Platform_Team/Recipe_Specification#.5BPackage.5D|sweets.recipe]] files. It is a kind of meta packaging, but restricted by design. As opposed to sweet packages, these packages will be placed in the {{Code|/usr}} directory.
+Where:
-=== Regular packages ===
+* {{Code|PROJECT}}, {{Code|REPOSITORY}}, {{Code|ARCH}} and {{Code|PACKAGE}}<br>identification of particular OBS package;
+* {{Code|withdeps}}<br>include dependencies graph of the {{Code|PACKAGE}};
+* {{Code|exclude}}<br>restrict dependency graph from bottom side.
-Regular packages is exactly how OBS was originally designed to work.
+For example,
+ https://obs.sugarlabs.org/resolve?project=OLPC:11.3.1&repository=Fedora-14&arch=i586&package=pygame&withdeps&exclude=sugar
+Will output:
+ <resolve>
+   <binary name="pygame" url="http://mock.laptop.org/cgit/koji.dist-f14-i686/plain/RPMS/pygame-1.9.1-3.fc14.i686.rpm" />
+   <binary name="SDL" url="http://mock.laptop.org/cgit/koji.dist-f14-i686-updates-11.3.1/plain/RPMS/SDL-1.2.14-11.fc14.i686.rpm" />
+   <binary name="SDL_mixer" url="http://mock.laptop.org/cgit/koji.dist-f14-i686/plain/RPMS/SDL_mixer-1.2.11-4.fc14.i686.rpm" />
+   <binary name="SDL_image" url="http://mock.laptop.org/cgit/koji.dist-f14-i686/plain/RPMS/SDL_image-1.2.10-1.fc13.i686.rpm" />
+   <binary name="numpy" url="http://mock.laptop.org/cgit/koji.dist-f14-i686/plain/RPMS/numpy-1.4.1-6.fc14.i686.rpm" />
+   <binary name="SDL_ttf" url="http://mock.laptop.org/cgit/koji.dist-f14-i686/plain/RPMS/SDL_ttf-2.0.10-1.fc14.i686.rpm" />
+   <binary name="portmidi" url="http://mock.laptop.org/cgit/koji.dist-f14-i686-updates-11.3.1/plain/RPMS/portmidi-200-5.fc14.i686.rpm" />
+   <binary name="libmikmod" url="http://mock.laptop.org/cgit/koji.dist-f14-i686/plain/RPMS/libmikmod-3.2.0-11.beta2.fc14.i686.rpm" />
+   <binary name="libgfortran" url="http://mock.laptop.org/cgit/koji.dist-f14-i686/plain/RPMS/libgfortran-4.5.1-4.fc14.i686.rpm" />
+   <binary name="python-nose" url="http://mock.laptop.org/cgit/koji.dist-f14-i686/plain/RPMS/python-nose-0.11.3-5.fc14.noarch.rpm" />
+   <binary name="python-setuptools" url="http://mock.laptop.org/cgit/koji.dist-f14-i686/plain/RPMS/python-setuptools-0.6.14-3.fc14.noarch.rpm" />
+   <binary name="atlas" url="http://mock.laptop.org/cgit/koji.dist-f14-i686/plain/RPMS/atlas-3.8.3-18.fc14.i686.rpm" />
+ </resolve>
+Note that {{Code|url}} attributes might be invalid if corresponding packages were used to building on OBS. So, keep special OBS projects, only for resolving purpose, like {{Code|OLPC}}.
 == Policy ==