Porting, Building and Installing LCFG Components on Solaris

Author: Craig Strachan

Last Updated 8th April 2005

This document offers some guidance on porting Linux LCFG components to Solaris 9 and details the procedure to follow when building and installing the package. It has been the author's experience that most components will port to Solaris with the minimum of modification. If these simple rules are not successful, building a package may require detailed examination of the buildtools and associated scripts, something which is outside the scope of this document.

Initial Preparations

First of all, the component to be ported must utilise the buildtools script. It is possible to produce Solaris packages without the aid of buildtools but this is not a recommended course of action. If you really need to do this, see here.

The user's path must include the following:

/opt/sfw/bin:/usr/sfw/bin:/usr/perl5/5.6.1/bin:/usr/local/bin

First you must check out the component using the cvs command. the version of ssh provided with Solaris can cause cvs problems so the openSSH version of ssh has been installed on Informatics Solaris workstations. To make sure you are using this version of ssh, type

export CVS_RSH=/usr/local/bin/ssh

Then check out the component using

cvs checkout lcfg-symlink

If this doesn't seem to work correctly, check the value of your $CVSROOT variable. It should look something like

<YOURUSERNAME>@cvs.inf.ed.ac.uk:/disk/cvs/dice

When your component is checked out, cd to the appropriate directory. For most components, three things need to be changed.

  • All calls to make must be replaced with the variable MAKE. The most common place for this this substitution to be necessary is in the package specfile where make would be replaced with @MAKE@.
  • All called to install must be replaced with the variable INSTALL. The most common place for this is in the component Makefile when install must be replaced with $(INSTALL)
  • All references to bash or bash2 must be replaced with the variable SHELL. the most common place for this substitution to be necessary is in the component code itself, normally called something like <componentname>.cin where the replacement would be @SHELL@.

    Other possible include replacing specific calls to the c compiler cc with the variable $(CC) (at present only gcc is installed on Solaris 9 machines) and changing the contents of the LIBS variable. An example of doing this is:

      ifeq ($(LCFGOS),SunOS)
         LIBS=-lsocket -lnsl
       else
         LIBS=
       endif
    
    

After making these replacements, an attempt can be made to build the package. As with Linux RPMS, you can opt to make a development or a release package The relevant commands are gmake devpkg and gmake pkg.

If when making a buildtools target you get error messages about an 'Unexpected end of line seen', you have used make rather than gmake. Make is broken under Solaris and you must use the GNU version.

You can also use all the other buildtool targets under Solaris. Built packages are in /var/tmp/pkgbuild though this behaviour can be changed by setting the $PKG_BUILD_DIR variable. Package names have a strict format and consist of a upper case repository name of no more than 4 letters followed by a lower case truncation of the package name of no more than 5 letters, follow by the version. There will normally be two packages produced for a LCFG component, the component itself named as above and a schema package where the component name is truncated to 3 letters followed by a 's' and the schema number. For example, at time of writing, the Solaris packages supplying the lcfg-client component were called LCFGclien-2.2.13-1 and LCFGclis3-2.2.13-1. Buildtools produces the packages in datastream format and gzips them so the full name of the client component package is LCFGclien-2.2.13-1.pkg.gz.

If the package doesn't build successfully, you are really heading out into unknown territory. One problem I have had is that pkgbuild expects commands in the %install and %postun sections to be on a single line. If the command is split over multiple lines, it will cause problems. Examining the specfile may give some clue as to the source of the problem, failing this it may be necessary to start putting debugging statements into the buildtools script to narrow down the source of the problem. In cases like this, please contact the Solaris team, we may well be able to help.

I've got my package, what do I do with it?

This depends. If you have produced a distribution package which you are happy to add to a repository, follow the instructions below. if you have produced a development package which you simply wish to try out, do the following:

  • Unzip the package using gunzip.

  • If an earlier version of the package is already install (you can find out which packages are installed on a machine using the pkginfo command), remove it with pkgrm <packagename> (you don't have to specify a version). E.g. to remove the client component, run pkgrm LCFGclien.

  • Add the new package using the pkgadd command. You will need to use the '-d' flag to this command which allows you to specify the location of the package. For example, to install the client component, you would run 'pkgadd -d /var/tmp/pkgbuild/LCFGclien-2.1.35-1.pkg'. Answer yes to any questions pkgadd asks you.

    To confirm that you have the correct version of the package installed, use 'pkginfo -x <package name>'.

To submit a package to the repository and make sure that it is installed on all Solaris machines, follow this procedure:

  • Decide which repository the package should go into.

    There are three repositories in which Solaris packages are stored, SUNW, LCFG and SFW. Packages which are part of the standard Sun distribution go in the SUNW repository. Packages which supply part of the LCFG system or which provide standard tools which have had to be amended to work with LCFG go into LCFG. Standard non-Sun packages which have been obtained from external sources or have been built from source and then packages without the use of Buildtools go into SFW (the name stands for Sun FreeWare, the site where many of these packages were obtained). The master copy of the repositories is on pezenas and is mounted on each Sun workstation under /repository.

  • Submit the package.

    Packages are added to repositories using the pkgsubmit command. If the package name begins with SUNW, LCFG or SFW, pkgsubmit will put the package into the correct repository automatically. If the package name does not start with one of these strings, you must specify the repository name by using the '--repository' flag. You can also give pkgsubmit a '--test' flag to see what pkgsubmit would try to do without anything actually happening. If a package is in directory format, pkgsubmit will automatically convert it to datastream format. If a package is not gzipped, pkgsubmit will also do this.

  • Add the package to the LCFG package list.

    If the package is not already in the relevant package list, you must add it. Use one of the package lists in the table below. All are in the Subversion repository, just like the Linux RPM package lists.

    Location in repository File Contains
    packages/lcfg lcfg_sol9_lcfg.pkgs LCFG components and their prerequisites
    packages/lcfg sun_sol9.pkgs Sun's own official Solaris packages
    packages/lcfg lcfg_sol9_addons.pkgs All other software for Solaris, e.g. SFW packages

    Just as in the Linux equivalents, wildcards can be used in the pkgs files.

  • Install the package on the workstations

    To install the new package, log into each Solaris workstation and run 'om updaterpms run' as ROOT (nsu should work).

Topic revision: r2 - 05 Jul 2007 - 10:34:16 - ChrisCooke
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies