openSUSE:Build Service private instance software delivery

Open Build Service> Build Service private instance

Use Cases - Requirements - Installation - Boot strapping - Software delivery - External partners - Software live cycle

Creating a bootable image

Once the OBS works, it will create repositories with rpm (source, binary and no Arch).

The creation of a bootable image is done by a tool called "Meego Image Creator" (MIC). MIC uses the Kick Start (ks] format to describe the installation of the Linux distribution which will then transfered to an image (various formats are supported). MIC can be used to create any Linux image from rpms repositories. You do not have to build a MeeGO image to benefit from MIC.

The Meego web site describes how to use MIC. Note : Some distributions include MIC in their repo but unfortunatly you will still often have to reinstall MIC from the source.

Note : If you want to use (or reuse) a package group such as @Core you will need to create these groups outside OBS with a tool called Createrepo.

Enabling a private repository

As long as you do not require the use of a Group, the repositories created by OBS are directly usable by rpm based package managers such as yum or zipper.

For example, to test a newly created package in your home directory, simply add a repo in your yum (or zipper) configuration, force a rescan of the repo and install your package with a simple yum install command. Note : if you have created a second version of a package which already existed in your base repo, then you will need to be aware of the rpm release and version number. If your modified package is based on a link to the source package (with modification), OBS will normally get the numbering right but if you have made a copy, OBS will have no way of tracking which one is the most recent. Advice : In a test environment, installing directly from the OBS repo is very useful and practical. For a production system, I would advise getting the QA team to replicate the OBS on a dedicated repo server and to let the customer load their software only from the repo server.

Adding group to a private repository

Groups can be useful to simplify the creation of images as they allow to associate a list of packages to a given group name. The file defining the packages groups is an xml file. Its structure is defined here

Once that you have the group.xml file created (or recovered from somewhere) you can add groups to your repo. This will require access to the file system containing your repo.

Create or Recover a group file (you will find them compressed in the repodata of repository if they have been added at the repo creation, under the name xxxxxgroup.xml.tgz)
Become root
Copy the file group.xml in the base of your repo where the group needs creation
Call the createrepo command
A new group.xml.tgz file is added in the reposdata directory of your target repo.
Change the new files owner back to obsrun

su
cp group.xml /obs/repos/meego-1.2.tv/standard/
cd /obs/repos/meego-1.2.tv/standard/
createrepo -g group.xml /obs/repos/meego-1.2.tv/standard/
chown obsrun:obsrun -R *

Note: That operation must be redone each time that the repo is modified by OBS (if someone as a method to automate that phase please add it here)

Signing or not signing

Signing takes time at every package creation. If you only do internal testing, signing is a useless loss of time.

For a real deployment signing your package is very good idea. You can let the OBS do it for you (by far the simplest) or do it when you transfer your packages to your dedicated repo server.

You will find a HowTo here

Delivering to an other OBS instance

When you need to deliver software to enable a customer or a partner to add software to your initial delivery, it is important to keep the flow simple, reproducible and capable of managing upgrade and update.

On line

Delivering software from an OBS when you have IP connectivity bewteen the source and the destination is very simple.

Simply create an ObsTag for the project that you want to deliver
If you do not allow Public connection, create an account for your customer on your OBS and let them upload your packages in their own OBS instance with the command "osc copypac" with the option "-t".
provide your customer with a copy of the utility obs2obscopy

Off Line (via rpm)

The delivery of code from an OBS instance without IP connectivity is a bit more complex.

The import of source rpm should only be used at the initial creation of a package because it will loose all the change history in the target OBS (for delivery of package update see see below (via tgz).

On the transmitting side

At the source you create a tar file with all the rpm sources that you want to deliver. Each file will have a name which represents the package name and its version.

On the receiving side,

With the OBS Web UI you create a project or sub project which will host these new packages (e.g. MeeGo:1.2:MyImportedProject)
On a workstation equipped with osc, you untar the received tar to get each rpm in an individual file.
move in the directory where the source rpm have been untar and create a file which contain the list of your rpm (with out the leading directories).

 cd /home/dominig/temp/untardir/
 ls *.rpm > rpm.lst

move to a working directory which will host the sources on your PC (anyone will do)
checkout of the newly created project (it will create a directory on you PC).

 cd /home/dominig/MeeGo/
 osc co MeeGo:1.2:MyImportedProject

move in the directory created by osc ("" might be needed).
use the command osc importsrcpkg in a small script to import all you packages in one go.

 cd "/home/dominig/MeeGo/MeeGo:1.2:MyImportedProject"
 for I in `cat /home/dominig/temp/untardir/rpm.lst` ; do  osc importsrcpkg -c  /home/dominig/temp/untardir/$I ; done

check with the OBS Web UI that your packages have been well transferred in OBS.

Note rpm source will not transfer any rpmlintrc rule and exception which might be needed to compile your code in OBS. More

Off Line (via tgz)

This procedure is a bit more complex but will not erase the package history in the receiving OBS.

The best method consists of

On the source system
- check out all the projects to be delivered and create a tar file of these projects.
On the target system
- create the same project and package hierarchy
- check them out
- untar the image of the checkout project on a tmp directory
- copy all the files from the tmp dir to the check-out dir
- use the command osc addremove on the check-out dir
- check-in the projects.

Note : This method will export any link as a copy.

Binary only

It is not uncommon that some modules cannot be delivered as source code to your customers while OBS will manage only Source rpm.

If you want to use the OBS to track your build versions, dependencies and build all your repo despite the fact that some packages are Binaries only, you can use the simple method which consists of creating a package with an empty build phase and with an install phase which copies the binary files into the same location that they would appear after a compilation.

Delivery of ready to run images

You can use mic2 (MeeGo image Creator) and a kickstart file (.ks) to create images ready to boot.

You will find the pointer on mic2 and .ks [here]