Plasma GitLab Archive
Projects Blog Knowledge

GODI Project:
Mailing List 
Why Ocaml? 
GODI is discontinued. This is the archived content of the former site
The new workgroup features in Skylift

1. Constraining package versions

Let's assume a workgroup of developers wants to create a software
platform with defined package versions. This means that for all
relevant packages the version to install is exactly set, and that
the build of these packages is reproducible.

How to do this?

First, we need to switch to the archive version of the standard
profile (because we want to copy and modify this profile):

$ godi_console profile -enable archive_4.00

(Use archive-3.12 if you still use OCaml-3.12.) The effect of the
archive profile is that all historic packages can be downloaded,
and not only versions from the last few months. The downside of this
is, and we gladly accept this, that certain operations take longer
(e.g. much more buildfiles are fetched from the GODI server).

Next step: We copy this profile.

$ godi_console profile -copy-to workgroup

This creates a new profile "workgroup" as a copy of the archive

Now we can add the package constraints. These need to be added to the
text file <prefix>/build/profiles/workgroup/profile.ini. You can find
some lines

include = *-*

in this file. One of these lines need to be modified, namely the line
in the section with "name = public_godirepo_4.00" (or 3.12).

Basically, "include" lists version constraints, e.g.

include = foo==4.3

would mean to install package "foo" in exactly this version. However,
we suggest you also add "*-*":

include = foo==4.3 *-*

because oftherwise ONLY package foo would be installable - the "*-*"
means to offer all unmentioned packages in the latest version.

You can of course list as many packages as you want:

include = foo==4.3 bar==6.4 *-*

The syntax allows more - it is the same as for dependencies in package

 - foo>3.4
 - foo>=3.4
 - foo<3.4
 - foo<=3.4
 - foo!=3.4

After editing the profile.ini file, you need to activate the new

$ godi_console profile -enable workgroup -update

The effect of the constraints is that the matching buildfiles are
unpacked and offered for build. So when you do

$ godi_console list

you'll see that the available versions ("src" column) take the
constraints into account. Note that you need to rebuild packages
if you want to upgrade or downgrade already installed packages.

Now we have managed to create such a profile on one computer. Do we
need to do the same on the other computers of the workgroup? Fortunately,
it is a bit easier here.

The direct way: Tar up the profile, and activate it somewhere else.
On the first computer do

$ godi_console rprofile -put workgroup -site /tmp

This creates a file "/tmp/workgroup.profile.tgz". Copy this file to the
second computer, and import it here:

$ godi_console rprofile -get workgroup -site /tmp

Of course, you can change /tmp to any other directory where you've put
workgroup.profile.tgz before. Even better, this can also be a web folder:

$ godi_console rprofile -get workgroup -site http://server/path

After that, you need only

$ godi_console profile -enable workgroup -update

to activate the profile.

2. Distributing binary packages

The idea is here to use one computer for building the packages, so
that they can be grabbed in binary form from the other computers of
the workgroup. Of course, it is a strict requirement that the
operating systems running on these computers are compatible.

Doing it the simple way: Whenever you build a package, the binary
file is put into <prefix>/build/packages/All/. Just copy these files
to a directory which is accessible from the other computers (e.g.
a shared folder, or accessible via web server):

$ cp <prefix>/build/packages/All/*.tgz <dir>

What is now missing in this directory is the PKGMANIFEST file (listing
the packages with selected metainformation). You can either take the
PKGMANIFEST file from <prefix>/build/packages/All/:

$ cp <prefix>/build/packages/All/PKGMANIFEST <dir>

Or you can regenerate this file:

$ cd <dir>
$ for f in *.tgz; do 
    godi_console ptool -in-binary "$f" -out-manifest; 

Now, how to direct the other computers to get the packages from here?
Set the directory for binary packages in godi.conf:


Remember that the directory can also be a URL (http, ftp). Now

$ godi_add foo

will search package "foo" also in this directory. Missing dependencies
are also resolved, but of course only from the binary packages in
<dir>. Of course, you can also use the UI of godi_console ("Select
binary packages").

Getting more control: Another option is to export every package
individually after the build. This way you get more control what is
made accessible to the team members.

Of course, you could just find out what the right files are in
<prefix>/build/packages/All/ - but this can be difficult, as sometimes
the package filenames only differ in the build checksum. A better way
is to take a snapshot once all packages are in a good shape.

In order to do so, define an export directory in godi.conf:

EXPORT_SOURCE = workgroup

Now change to a directory in the build hierarchy, e.g.

$ cd <prefix>/build/conf/conf-pcre

(it does not matter which one). Now do for every package "foo" you'd like
to export

$ godi_make export-package PKGNAME=foo

The effect is that a copy of the currently installed package "foo" is
packed up as a new binary file, and written to $EXPORT_DESTDIR/packages.
The PKGMANIFEST in this directory is automatically updated.

This web site is published by Informatikbüro Gerd Stolpmann
Powered by Caml