Difference between revisions of "School Network/Open Build Service"
| Line 3: | Line 3: | ||
This is a [http://git.sugarlabs.org/0sugar/build-service patched] Sugar Labs instance of [http://openbuildservice.org/ Open Build System] (OBS) that is intended to be a: | This is a [http://git.sugarlabs.org/0sugar/build-service patched] Sugar Labs instance of [http://openbuildservice.org/ Open Build System] (OBS) that is intended to be a: | ||
| − | * | + | * Place to host sources and to make binaries, if there is need, for [[Platform_Team/Sweets|Sweets]]. |
* Convenient instrument to create 3rd party repositories with native packages for all [[#Supported_platforms|supported]] GNU/Linux distributions. | * Convenient instrument to create 3rd party repositories with native packages for all [[#Supported_platforms|supported]] GNU/Linux distributions. | ||
| Line 12: | Line 12: | ||
=== obs.sugarlabs.org === | === obs.sugarlabs.org === | ||
| − | This is an [https://obs.sugarlabs.org/apidocs/ API] site, all OBS clients use it to get access to OBS. There is no need to work with site directly but | + | This is an [https://obs.sugarlabs.org/apidocs/ API] site, all OBS clients use it to get access to OBS. There is no need to work with the site directly, but that is [http://en.opensuse.org//openSUSE:Build_Service_Curl possible]. |
| − | + | The site uses HTTP Basic authentication. To get access, [[Service/Account#Sugar_Labs_Central_Login|create]] a Sugar Labs Central Login account. | |
=== packages.sugarlabs.org === | === packages.sugarlabs.org === | ||
| − | This is an original OBS Web client. It is intended to be used only by people who need to create native packages, i.e., not for most | + | This is an original OBS Web client. It is intended to be used only by people who need to create native packages, i.e., it is not needed for most Sugar developers. But, until a more appropriate tool is created for Sugar needs, it is the only Web client available to manage already released software (those released by being processed by the [[Platform_Team/Guide/Sweets_Packaging#Releasing|sweets command]]). |
== Content == | == Content == | ||
| − | The | + | The content on OBS might be of several kinds: |
=== Projects === | === Projects === | ||
| − | Projects are directories of Packages and might be two types: | + | Projects are directories of Packages and might be of two types: |
* top level, regular projects, like {{Code|base}} or {{Code|sdk}}; | * top level, regular projects, like {{Code|base}} or {{Code|sdk}}; | ||
| Line 35: | Line 35: | ||
Packages represent particular software projects and contain all files associated with these projects, e.g., tarballs with sources. | Packages represent particular software projects and contain all files associated with these projects, e.g., tarballs with sources. | ||
| − | There are several types of | + | There are several types of packages supported on OBS: |
* packages that represent sweets, | * packages that represent sweets, | ||
* native packages based on sweets, | * native packages based on sweets, | ||
| − | * native packages | + | * native packages using sweet recipes as spec files, |
* aliases, | * aliases, | ||
* regular OBS packages. | * regular OBS packages. | ||
| Line 47: | Line 47: | ||
=== Repositories === | === Repositories === | ||
| − | Every project has repositories to build its packages against. Repositories might be two types: | + | Every project has repositories to build its packages against. Repositories might be of two types: |
* inherited from another project; | * inherited from another project; | ||
| − | * initial repositories, aka downloaded-on-demand, that are associated with particular GNU/Linux distribution release; | + | * initial repositories, aka, downloaded-on-demand, that are associated with a particular GNU/Linux distribution release; |
| − | * {{Code|sweets.sugarlabs.org}} repository should present if Packages need to be distributed via Zero Install. | + | * {{Code|sweets.sugarlabs.org}} repository should be present if Packages need to be distributed via Zero Install. |
| − | Every repository has supported architectures, e.g., {{Code|i586}} or {{Code|x86_64}}. There is also special architecture, {{Code|0install}}, only for {{Code|sweets.sugarlabs.org}}. | + | Every repository has supported architectures, e.g., {{Code|i586}} or {{Code|x86_64}}. There is also the special architecture, {{Code|0install}}, only for {{Code|sweets.sugarlabs.org}}. |
== Supported platforms == | == Supported platforms == | ||
Revision as of 20:18, 18 October 2011
Summary
This is a patched Sugar Labs instance of Open Build System (OBS) that is intended to be a:
- Place to host sources and to make binaries, if there is need, for Sweets.
- Convenient instrument to create 3rd party repositories with native packages for all supported GNU/Linux distributions.
For detailed information, read the original Open Build System documentation.
Sites
obs.sugarlabs.org
This is an API site, all OBS clients use it to get access to OBS. There is no need to work with the site directly, but that is possible.
The site uses HTTP Basic authentication. To get access, create a Sugar Labs Central Login account.
packages.sugarlabs.org
This is an original OBS Web client. It is intended to be used only by people who need to create native packages, i.e., it is not needed for most Sugar developers. But, until a more appropriate tool is created for Sugar needs, it is the only Web client available to manage already released software (those released by being processed by the sweets command).
Content
The content on OBS might be of several kinds:
Projects
Projects are directories of Packages and might be of two types:
- top level, regular projects, like
baseorsdk; - user's home projects, like
home:<user>.
Packages
Packages represent particular software projects and contain all files associated with these projects, e.g., tarballs with sources.
There are several types of packages supported on OBS:
- packages that represent sweets,
- native packages based on sweets,
- native packages using sweet recipes as spec files,
- aliases,
- regular OBS packages.
See Usage section for more details.
Repositories
Every project has repositories to build its packages against. Repositories might be of two types:
- inherited from another project;
- initial repositories, aka, downloaded-on-demand, that are associated with a particular GNU/Linux distribution release;
sweets.sugarlabs.orgrepository should be present if Packages need to be distributed via Zero Install.
Every repository has supported architectures, e.g., i586 or x86_64. There is also the special architecture, 0install, only for sweets.sugarlabs.org.
Supported platforms
There is special project, named base, it contains all GNU/Linux distributions that are supported on OBS. All other projects need to inherit repositories from this project.
Usage
There are several OBS usage workflows.
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,
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
baseproject; - Go to OBS package that represent a sweet you need to build native packages for, e.g., 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 /opt directory instead of regular /usr. The reason is that sweets are not indented to be placed directly to the /usr and there might be file name collisions with existed files.
Recipe based packages
These are regular OBS packages except that instead of regular spec files, e.g., RPM .spec, they might be build basing on 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 /usr.
Regular packages
It is exactly how OBS is originally designed to work.
Policy
Resources
- Open Build system home page.
- API specification.
- Downstream patch sources.