Creating Solaris Pkg Files From Already Installed Packages

Please click above for a larger resolution version of the sample output shown.

Hey again,

For today, I put together a shell script, in ksh, to create new Solaris pkg files from already installed packages. The motivation for this sometimes seems hard to explain since you generally don't really "need" to have packages of any software that's installed on your system. It's there already; plus you probably have the install CD or a JumpStart server sitting around somewhere on your network with the original installation packages on them, right?

Other options we've looked at in previous posts include using pkg-get to help you out in a pinch and, if you have the means, creating your own packages from source quickly and making them the long, hard old-fashioned way. For today, we're going to assume none of these avenues are available to you.

I've found that, on more than several occasions, I've been stuck on a machine which needed a package installed and been out-of-luck on both counts (No software CD's and no Network Install Server). And some packages are hard to come by, like some of the obscure, but almost absolutely necessary, Solaris system packages like SUNWexplo. Well, okay, you don't really "need" to have Sun Explorer installed on your machine either, but it's usually the first output Sun's phone support requests you send them, so let's just pretend it's essential for argument's sake ;)

With today's script (called, simply, pkgremk <--- Slight homage to pkgmk since we're remaking the packages ;) you can take any pkg that's installed on your Solaris system and create a perfectly valid datastream package for use on any other machine of suitably similar or compatible architecture and/or Solaris Unix version.

So, for example, if you found yourself in a situation where you were stuck without Sun's Explorer to gather evidence on your Solaris 9 box, you needed to run it to send to Sun support and you had it on a second Solaris 9 box, you could run pkgremk on the second box, transfer the pkg from the second box to the first, install Explorer and run it right then and there! Kind of like this (Glossing over tons of little things here ;)

host b # ./pkgremk SUNWexplo
host b # scp SUNWexplo.pkg hosta:/home/user1/.

host a # pkgadd -d /home/user1/SUNWexplo.pkg
host a # /opt/SUNWexplo/bin/explorer <--- And the data collection begins.

It's really pretty much that simple. The only things the pkgremk script requires are that you already have the software installed on the server that you want to "remake" the package on, and that you pass it the exact package name as the only argument on the command line (you can find this information out easily by either doing an ls of the /var/sadm/pkg directory or just running pkginfo with no arguments).

I tried to take into account all parts of the pkg making process and accounted for getting all the package file names, types and ownership/permission information from /var/sadm/install/contents, as well as all the pkginfo, dependency and installation files in /var/sadm/pkg and playing with those so that you could, literally, type one quick command line and create any package you need to replicate on your machine, for whatever reason, and be able to use it just about anywhere else (On Solaris, of course - I'll be doing this for Linux soon, as well :) The finished product should be easy to move around since we use pkgtrans to make it a single file datastream format package, rather than a directory structure that you'd have to tar up and mess around with. Basically, you're going to be getting a Sun standards-compliant pkg software distribution file!

This script could be nice for insurance purposes, as well. If, for instance, you weren't sure you wanted to remove the CSWtop package. If you didn't have the pkg file you got originally, you could just create it on the fly and then re-install from that new package if you found you really did need it, like so:

host # ls -d /var/sadm/pkg/CSWtop
/var/sadm/pkg/CSWtop
host # ./pkgremk CSWtop <--- See the picture above for the full command output
...
Done!
host # ls
CSWtop.pkg CSWtop_mk.12473.out
host # pkgrm CSWtop
...
Removal of <CSWtop> was successful.
host # top
bash: top: command not found <--- For our example's sake, you've just realized how desperately you need top ;)
host # pkgadd -d CSWtop.pkg <--- or "pkgadd -d /full/path/to/CSWtop.pkg" if you're not in the same directory as the package.

A few keystrokes, and you're back in business :) I hope this script helps you out and you can find even more good uses for it!

Best wishes,





This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/bin/ksh

#
# pkgremk - Create pkgs from existing installations on Solaris
#
# 2008 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#

trap 'cd $orig_pwd;rm -rf $tmp_dir;rm -rf ${pkgname}_mk.out;exit' 1 2 3 9 15

if [ $# -ne 1 ]
then
 echo "Usage: $0 PKGname"
 echo "Package must be installed on system"
 exit
fi

pkgname=$1
orig_pwd=`pwd`

if [ ! -d /var/sadm/pkg/$pkgname ]
then
 echo "$pkgname does not exist in the pkg repository.  Exiting..."
 exit
fi

tmp_dir=pkgremk.$$

if [ -d $tmp_dir ]
then
 echo "Removing existing temp dir"
 rm -r $tmp_dir
else
 echo "Creating temp work directory..."
 mkdir $tmp_dir
fi

cd $tmp_dir

echo "Copying over \"install\" directory"
(cd /var/sadm/pkg/$pkgname;tar cpf - install)|tar xpf -

echo "Copying over pkginfo file"
cp /var/sadm/pkg/$pkgname/pkginfo .

if [ -f prototype ]
then
 rm prototype
fi

echo "Deriving new prototype file"
echo "Generating includes"
if [ -f pkginfo ]
then
 echo "i pkginfo" >>prototype
else
 echo "pkginfo disappeared.  Package will not build.  Exiting..."
 exit
fi

cd install
ls -1d * 2>/dev/null|while read line
do
 echo "i $line"
 echo "i $line" >>../prototype
 mv $line ../
done

cd ..

if [ -d install ]
then
 echo "Removing install directory"
 rm -r install
fi

grep $pkgname /var/sadm/install/contents |cut -d' ' -f 1,2,3,4,5,6|awk '{print $2 " " $3 " " $1 " " $4 " " $5 " " $6}'>>prototype

orig_basedir=`grep BASEDIR pkginfo|awk -F"=" '{print $2 "/"}'`
old_basedir=`grep BASEDIR pkginfo|awk -F"=" '{print $2 "/"}'|sed 's/\//\\\\\//g'`
if [ $orig_basedir = "//" ]
then
 orig_basedir="/"
fi
if [ $old_basedir = "\/\/" ]
then
 old_basedir="\/"
fi

echo "Stripping pathnames to compensate for BASEDIR=$orig_basedir"
echo "directive in pkginfo file"
this_temp=$$
sed "s/$old_basedir//" prototype >>$this_temp
mv $this_temp prototype

echo "Removing non-pkginfo/pkgmap lines from prototype"
that_temp=$$
awk '{ if ( $1 ~ /^[ifcsd]/ ) print $0}' prototype >>$that_temp
mv $that_temp prototype

echo "Creating distributable pkg from existing files as ${pkgname}.pkg"
echo "Output of pkgmk command dumping to ${pkgname}_mk.out"
/usr/bin/pkgmk -b $orig_basedir -d /tmp >${orig_pwd}/${pkgname}_mk.$$.out 2>&1
cd ..
echo "Transferring package to datastream format"
if [ -f `pwd`/${pkgname}.pkg ]
then
 tmp_pid=$$
 echo "Found existing `pwd`/${pkgname}.pkg file"
 echo "Copying to `pwd`/${pkgname}.pkg.$tmp_pid"
 mv `pwd`/${pkgname}.pkg `pwd`/${pkgname}.pkg.$tmp_pid
fi
/usr/bin/pkgtrans -s /tmp `pwd`/${pkgname}.pkg $pkgname
rm -r /tmp/$pkgname

echo "Done!"
cd $orig_pwd
rm -rf $tmp_dir

, Mike

linux unix internet technology

Using Pkg-Get On Solaris To Emulate Linux Apt-Get

Hi again,

Today I thought we'd take a look at Unix and address an issue that most of us have probably had with installing software on most flavors of it. It seems like Linux picked up all the good stuff (or, at least, made it more accessible) first. And, while it's true that "Open Solaris" and even HP-UX (with pkg-utils) are starting to move toward ease of installation, they've got a long way to go to catch up with the open-source community who've been endeavouring to accommodate all sorts of alternative software packages (and packaging systems) since their inception.

Tools like up2date, urpmi, yum and apt (to mention the ones that come to mind right away) on all manner and type of Linux systems and distributions have been making it easier for the user to download package dependent software for a long time now.

Now, by package dependent software, I'm referring to, let's say, an open source package called "TheProgram." You download and attempt to install it only to find out that it relies on libraries from "TheOtherProgram" and "SomeOtherProgram" in order to compile. So you download those, but they require "Software Packages A, B and C" to be installed, etc. You see where this is going. If you're like me, it's probably nowhere unless your getting "TheProgram" installed is a job requirement ;)

Software like apt (with apt-get) and yum, etc, make life easier for you by not only downloading and installing the software you request, but also gathering, downloading and installing all of the other software you're going to need to get "TheProgram" to run. Of course, they're kind enough to ask you to confirm at each step, but I don't consider that an annoyance. If I ever get frustrated, I just think about the worst that could happen if apt-get didn't ask me whether I wanted to destroy my machine or not ;)

Many of you may have heard of pkg-get, which you can download freely from the web. There are also some great resources out there devoted to getting the most out of the Solaris pkg-get program.

pkg-get provides much the same functionality as apt-get, except that pkg's get installed instead of rpm's. It seems to be a bit more on the verbose side, but, in terms of execution, and a large collection of open source software to choose from in its publicly available repositories, its an excellent alternative to doing everything yourself. I'd imagine it's probably a better alternative to most other software packages that do the same thing for Unix (although I can't seem to find more than the two I mentioned above that aren't hacked-up versions of Linux utilities fudged into working on a Unix box).

Below, I've included a sample run (from a "clean" box), where I decided to install "aspelluk." This will give you an idea of how robust the pkg-get software and it's supporting repositories are. Consider the ellipses (...) filler for the output of http redirections and pkgadd commands, of which there are quite a few in my request. As with all software installations on Solaris, I was prompted at each step to make sure I was aware of what I was doing ;) I thought this would be a good example since I'd be installing an addition (aspelluk - The UK add-on for aspell) to a program I knew I didn't have installed (aspell - spelling checker).

Cheers,

host # pkg-get -i aspelluk
Trying http://mirrors.usc.edu/pub/blastwave/unstable/sparc/5.9/aspelluk-1.3.1.0-SunOS5.8-all-CSW.pkg.gz
...
Trying to install dependancy common
...
Processing package instance <CSWcommon> from </var/pkg-get/downloads/common-1.4.5-SunOS5.8-sparc-CSW.pkg.gz.tmp>
...
Installation of <CSWcommon> was successful.
Trying to install dependancy aspell
...
Trying to install dependancy gcc3corert
...
Processing package instance <CSWgcc3corert> from
...
Installation of <CSWgcc3corert> was successful.
Trying to install dependancy gcc3g++rt
...
Processing package instance <CSWgcc3g++rt> from </var/pkg-get/downloads/gcc3g++rt-3.4.5-SunOS5.8-sparc-CSW.pkg.gz.tmp>
...
Installation of <CSWgcc3g++rt> was successful.
Trying to install dependancy ggettext
...
Trying to install dependancy libiconv
...
Processing package instance <CSWiconv> from </var/pkg-get/downloads/libiconv-1.9.2-SunOS5.8-sparc-CSW.pkg.gz.tmp>
...
Installation of <CSWiconv> was successful.
Trying to install dependancy expat
...
Processing package instance <CSWexpat> from </var/pkg-get/downloads/expat-1.95.7-SunOS5.8-sparc-CSW.pkg.gz.tmp>
...
Installation of <CSWexpat> was successful.
Processing package instance <CSWggettext> from
...
Installation of <CSWggettext> was successful.
Processing package instance <CSWaspell> from </var/pkg-get/downloads/aspell-0.60.5-SunOS5.8-sparc-CSW.pkg.gz.tmp>
...
Installation of <CSWaspell> was successful.
Trying to install dependancy bzip2
...
Processing package instance <CSWbzip2> from
...
Installation of <CSWbzip2> was successful.
Processing package instance <CSWaspelluk> from </var/pkg-get/downloads/aspelluk-1.3.1.0-SunOS5.8-all-CSW.pkg.gz.tmp>
...
Installation of <CSWaspelluk> was successful.

, Mike

linux unix internet technology

Beginning Your Spec File For Building Linux RPM's.

Hello Again,

This is a continuation of yesterdays post on doing the initial build of your software as the first step toward creating your own Linux RPM. Today we're going to continue on that path with our software package (cleverly named PACKAGE-3.2-1 ;) and move on to the next step in the RPM creation process; the creation of the specification file (which I'll refer to as the "spec file" from here on out) and its basic structure.

For the purposes of our example, we won't be including every single option you can include in a spec file, but we'll touch on all the required ones, and a few that might make your life a bit easier :)

We'll create our spec file by simply opening it up as a new file in our favorite editor. The spec file is simply a plain text file, describing our RPM's attributes, that we'll be supplying to the "rpmbuild" command later on. We'll look at the spec file, line by line, for our soon-to-be-completed package. We'll call it PACKAGE.spec

The first section is what I like to call the "header section," although I don't know that it's ever actually referred to as that. It looks like the following

Summary: The World Famous PACKAGE software
Name: PACKAGE
Version: 3.2
Release: 1
Copyright: Gnu Public License
Group: Applications
Source0: PACKAGE-3.2-1.tar.gz
Prefix: /usr/local
Provides: PACKAGE3, PACKAGE-devel, bunk
Requires: PACKAGE1, db
URL: http://xyz.com
Packager: Mike Tremell
# %define _topdir /users/me/softbuilds/rpm
%description
PACKAGE 3.2-1 Standard Build
%define PACKAGEDIR %{prefix}

The lines in this section are defined as follows:

Summary - This line should be a descriptive summary of your RPM package, in short form. It shouldn't be too wordy, but you can make it as long as you want.

Name - This is simply the name of your package. It must match the source package's name (which we created in /usr/src/packages/SOURCES/ in yesterday's post on setting up the initial build for your RPM. It will later be used (with the Version and Release keyword values appended) by rpmbuild to determine what source file it should look for in /usr/src/packages/SOURCES

Version - The version of your software. Again this must be exactly the same version of the source package you're building from.

Release - The release of the software. This, again, must be exactly the same as the release you're building from. Using the "Name," "Version," and "Release" variables, rpmbuild will surmise that we want to build our RPM from PACKAGE-3.2-1.tar.gz in /usr/src/packages/SOURCES. Note: The Release variable is required and (for whatever reason) cannot be an empty value. Thus we put in the obligatory 1 for our new build of the generic PACKAGE software. Whatever you're building will probably have a release number.

Copyright - Just attribution for the package and/or package source's author(s)

Group - This identifies our package as belonging to the "Applications" package group in Linux.

Source0 - The name (Yes, this is redundant ;) of the source package in /usr/src/packages/SOURCES. As the name implies, you can have more than one source in certain circumstances. Note that there is also a "Patch0," etc, declaration that you can use to specify diff files you may need to include, but that's beyond the scope of our exercise.

Prefix - The root under which the RPM will install itself. Note: You need to include the Prefix declaration if you want your RPM package to be "relocatable." If your package is not relocatable, all installs will always install to the same place. If your package is relocatable, it allows the user or administrator to change the prefix, or root install directory, of the RPM when they run the "rpm" command to install it!

Provides - What your RPM will "provide" once it is installed. This is mainly for rpm's dependency checking. You can have your package provide anything, but it's best to have it provide only useful values. This variable isn't necessary if your software package isn't providing anything significant and/or doesn't have another package that's dependant on it.

Requires - The RPM packages your RPM package needs to have installed on your system before it will install correctly. In our example, PACKAGE will not install correctly (it will fail the dependency check) if some version of the "db" (Berkeley Database) RPM isn't already installed on our system.

URL - The location where a user can download the latest version of the RPM source. Not necessary, but can be helpful.

Packager - The name of the guy (or gal) who put together the RPM. Again, not necessary unless you're seeking notoriety ;)

# %define _topdir /users/me/softbuilds/rpm - Note that this line is commented out for our build, since we're going with the system defaults. However, comments in spec files work just like comments in shell scripts, so if you wanted to change the top level directory for your RPM structure, you could do it by redefining the _topdir variable (In this case, simply by removing the comment). You may need to create its required BUILD, BUILDROOT, RPMS, SOURCES, SPECS and SRPMS subdirectories manually. This option is useful if you're trying to do a build as a regular user and don't have the system privilege that will allow you to manipulate your server's main RPM package working directories :)

%description - Just like the summary above, but should be more descriptive. Also, you should add your description on a new line following the %description declaration (unlike all the others). "rpmbuild" will spew error messages if you put your description's value on the same line as the variable. You can actually include "one" word on the same line as the %description variable, but the rest of your description must be below that line. It should also be noted that you can have multiple %description declarations, which is useful if you're building multiple RPM's from one spec file (although that's deeper than we want to go for now).

%define - This directive can be used over and over again. It's simple format is: %define variable_name value. You can call the variable name you define here using the %{} notation. For instance:

%define mydir /usr/local/bin

Would allow you to reference /usr/local/bin, at any point (from the point of definition on) in your spec file as %{mydir}

Tomorrow, we'll check out the next, and final section of the RPM spec file and use "rpmbuild" to create our RPM package!

Cheers,

, Mike

linux unix internet technology

Working with Linux RPM's

This post is a continuation, of sorts, of my last post. This is more of a general-audience post. Most experienced admins know most of this stuff already. Like I mentioned previously, I try to write this blog with an appreciation for what it was like when I first started out in the business. I owe my success to a great many patient and helpful people.

In this post, I wanted to hit on the basics of working with RPM's in Linux (RPM stands for the Redhat Package Management system - basically, they're the software packages that make up your system). In later posts we'll go into some neat tricks... But for now, we'll stick with the basics. Knowing the basics in any field of interest is invaluable in growing and mastering that skillset, just like knowing your ABC's can really help if you ever intend to read or write :)

Check the bottom for a recap of all the RPM options we're going to use and their literal meanings:

1. To display the basic information for any RPM, just type:

host # rpm -qi RPM_NAME - like:

host # rpm -qi bash
Name : bash Relocations: /usr
Version : 2.05 Vendor: Red Hat, Inc.
Release : 8.2 Build Date: Mon 28 Jun 2004 10:33:55 AM CDT
Install date: Thu 12 Jan 2006 01:25:27 PM CST Build Host: host.redhat.com
Group : System Environment/Shells Source RPM: bash-2.05-8.2.src.rpm
... EDITED OUT FOR BREVITY'S SAKE!

2. If you're not sure where to start with the above command, just have RPM spit out all the packages it knows about and pipe that to more, like so:

host # rpm -qa|more
redhat-logos-1.1.3-1
glibc-2.2.4-32.18
cracklib-2.7-12
dosfstools-2.7-1
gdbm-1.8.0-11
...

3. Now that you've figured out what package you want to inspect (Note that you don't have to include the full name to get the information from RPM. The redhat-logos-1.1.3-1 program can be referred to simply as redhat-logos) and have gotten some basic information about it, you can list out all the files associated with the package like this:

host # rpm -ql bash
/bin/bash
/bin/bash2
/bin/sh
/etc/skel/.bash_logout
...

4. Here's one that doesn't require a lot of output, since it's somewhat of a re-explanation. You can add the -p flag to the examples in points 1 and 3 if you're querying an RPM package, and not the RPM database!

host # rpm -qip bash-2.05-8.2.i386.rpm <--- Listing out information for the RPM package itself.
host # rpm -qlp bash-2.05-8.2.i386.rpm <--- Listing out files associated with the RPM package itself.

5. Of course, you may find a file and want to know what RPM package it belongs to. You can get that by typing:

host # rpm -qif /etc
Name : filesystem Relocations: (not relocateable)
Version : 2.1.6 Vendor: Red Hat, Inc.
Release : 2 Build Date: Mon 20 Aug 2001 03:34:02 PM CDT
Install date: Thu 12 Jan 2006 01:24:41 PM CST Build Host: host.redhat.com
Group : System Environment/Base Source RPM: filesystem-2.1.6-2.src.rpm Vendor: Red Hat, Inc.
... (Just as long as the description in point 1)

6. If you want to install a new RPM, you'll need the package file, and would run RPM like this:

host # rpm -i bash-2.05-8.2.i386.rpm

This isn't very interesting (which may be what you want -- I don't care to look at verbose output "all" the time). You can spice it up by adding the -v and/or -h flag, like so:

host # rpm -ivh bash-2.05-8.2.i386.rpm

7. If you want to uninstall an RPM, you'll just need to know the abbreviated name, like I mentioned in point 4). You can also make this as verbose and visually entertaining as the system will allow with -v and/or -h:

host # rpm -e bash

Note that this command would return an error if you had multiple instances of the bash RPM installed. In that case, you could still abbreviate, but would have to include the version number. So you'd type

host # rpm -e bash-2.05.8.2

instead of just bash.

So, to recap, and possibly explain anything I may have glossed over, these basic commands should get you started working with the RPM package management facility on Linux. The translations of the flags we've covered are as follows:

Major flags (usually the ones preceded with a dash, but you can arrange the flags in whatever order you choose - just be careful - see note in the minor flags):

q = query
i = install
e = remove/uninstall

Minor flags

i = information (not the same as the major flag i. Of course, you'll probably never use -ii or -ei, as the combinations would be redundant and opposite, respectively.
a = all
l = list
p = RPM package file (e.g. whatever.rpm)
f = file
v = verbose
h = hash (prints lots of # symbols while it completes your request :)

Enjoy getting started working with RPM packages. They're one of the foundations of the Linux operating system. In fact, a combination of certain packages actually "is" the operating system. Knowing how to manipulate them and have them work for you can make it easier to explore many other things (like new software you've always wanted to install and try out :)

Best wishes,

, Mike

linux unix internet technology

Making Your Own Solaris Packages!

While there are more than a few ways to pack up and distribute software distro's you've either downloaded and custom-compiled, or built yourself from scratch, if you work on a lot of Solaris boxes, it's nice to be able to produce legitimate "pkg" files to showcase your efforts.

Today, we'll look at how easily this can be done (although, of course, many other methods are much much less drawn-ouot). After reading through this post, you should be able to create your own "pkg" files and even (we'll look at this in some detail in a future post) script out and automate the process with a little ingenuity :)

For the purposes of this post, we'll assume that we're going to build the latest version of PROGRAM (pardon my lack of originality in naming ;)

1. First, ensure that you have the disk space and compile your program with the "--prefix" suffix (pretty much standard now with all publicly available source builds):

cd /tmp/PROGRAM_SOURCE
./configure --prefix=/usr/local/builds/PROGRAM
make
make install

2. Now you should have your program built and installed under /usr/local/builds/PROGRAM, with all the subdirectories beginning there (e.g. /usr/local/builds/PROGRAM/bin, /usr/local/builds/PROGRAM/sbin, etc). Make sure that all the files have the ownership and permissions that you will want them to have when your "pkg" file is complete!

3. Now we'll create the "prototype" file. Add all necessary links (like usr=/usr) for all subdirectories that you want your package to unpack into. We're going to assume that your package is going to unpack into the root directory (/) like most Solaris "pkg" files:

cd /usr/local/builds/PROGRAM
find . -print|pkgproto usr=/usr bin=/bin sbin=/sbin etc=/etc >prototype

4. Then, add pointers to the prototype file. You'll "need" one to the "pkginfo" file that we'll create soon, and you can also create entries for "preinstall," "postinstall" and "checkinstall" files, although they're not completely necessary. "checkinstall" is a good file to have if you want to be able to ensure that your package won't install if it is somehow corrupt or not being installed on a proper system.
Note that the "checkinstall" script is run by the user "nobody," and runs automatically, so your source needs to be accessible for checks by that user in order for it to work correctly. "preinstall" and "postinstall" are run as "root" and prompt the user to run them. You can also add a line to reference a script to check dependencies within the "prototype" file of the form "depend=/path/to/depend/script." Add the following to the top of the /usr/local/builds/PROGRAM/prototype file:

i pkginfo
i checkinstall

5. Now create a "pkginfo" file with the basics:

SUNW_PRODNAME="SunOS"
SUNW_PRODVERS="5.10"
SUNW_PKGTYPE="usr"
PKG="PROGRAM"
NAME="The PROGRAM Progam"
VERSION="1.0"
ARCH="sparc"
VENDOR="XYZ, Inc."
EMAIL="insertyouremailhere"
CATEGORY="system"
ISTATES="S 1 2 3"
RSTATES="S 1 2 3"

Lots of these aren't necessary, and are self explanatory. ISTATES are the acceptable run levels in which the package can be installed. RSTATES are the acceptable run levels in which it can be removed.

6. And create a simple "checkinstall" file as well (both the "pkginfo" and "checkinstall" files need to be in the same directory as the "prototype" file and the software - in our case /usr/local/builds/PROGRAM):

#!/bin/sh

# Sample checkinstall script

platform_should_be="sparc"
platform=`uname -p`
if [ ${platform} != ${platform_should_be} ]
then
echo "PROGRAM can only be installed on ${platform_should_be}"
exit 1
fi
exit 0

7. Now, we're finally ready to create the package with "pkgmk" and "pkgtrans":

cd /usr/local/builds/PROGRAM <--- just in case we wandered off
pkgmk -b `pwd` -d /tmp <--- "-b" is your source base diretory and "-d" indicates the "device" (in this case, the /tmp directory) into which you want to build the actual "pkg" file.
pkgtrans -s /tmp /usr/local/builds/PROGRAM.pkg PROGRAM.pkg <--- The "-s" indicates that you want to translate the PROGRAM.pkg file in /tmp in datastream format as /usr/local/builds/PROGRAM.pkg

Now you're all set to grab the PROGRAM.pkg file from the /usr/local/builds directory and install it with "pkgadd" on any Solaris system you want to (depending, of course, on the restrictions you put in place in your "checkinstall" - and possibly "depend" - script)!

, Mike

linux unix internet technology