Difference between revisions of "School Network/Open Build Service"

From Sugar Labs
Jump to navigation Jump to search
Line 78: Line 78:
  
 
* Create a new project;
 
* Create a new project;
−
* Add packages that need to be built for, they should be directly or indirectly inherited from the {{Code|base}} project;
+
* 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];
 
* 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.
 
* Click the ''Link sweet package'' link to add it to your project.

Revision as of 08:36, 30 October 2011

Summary

This is a patched Sugar Labs instance of the Open Build System (OBS), which is intended to be a:

  • Place to host sources and to make binaries, if there is a need, for Sweets projects.
  • 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 base or sdk;
  • 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;

Note: The sweets.sugarlabs.org repository 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 a 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 a need, to build binaries. There are two ways to interact with OBS:

  • Console based client, sweets, for uploading new releases;
  • 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.

Sweet packages

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

  • Create a new project;
  • Add repositories that packages need to be built for, they should be directly or indirectly inherited from the base project;
  • Go to the OBS package that represents a sweet you need to build native packages for, e.g., 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 /opt directory instead of the regular /usr. The reason for this is that sweets are not intended to be placed directly in the /usr directory as there might be file name collisions with existing files.

Recipe based packages

These are regular OBS packages except that instead of regular spec files, e.g., RPM .spec, they might be built based on 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 /usr directory.

Regular packages

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

Policy

  1. REDIRECT School Network/Open Build Service/Policy

Resources

Retrieved from "https://wiki.sugarlabs.org/index.php?title=School_Network/Open_Build_Service&oldid=70539"