---------------------------------------------------------------------- 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 profile. 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 definitions: - 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 profile: $ 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; done >PKGMANIFEST Now, how to direct the other computers to get the packages from here? Set the directory for binary packages in godi.conf: GODI_BINPKG = <dir> 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_DESTDIR = <dir> 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.