How it works

The following is a simple description of how parts of the package tools system works.

• build-pkg
• chroot-install

build-pkg

build-pkg performs its job by doing the following:

• Reading in the configuration file if it exists. By default the configuration file is $HOME/.build-pkg This can be changed by the use of the -C command line option.

• Working out if its dealing with a perl module or not; they are handled differently. It is assumed that we are dealing with a perl module if the blib directory exists under the current working directory.

  Note that the -P option can be used to say that we are not dealing with a perl module, even if the blib directory does exist under the current working directory.

• Creating the required directories, i.e. the work directory.

• If it doesn't already exist create the pkginfo file for the package. This is done by asking the user a series of questions. Each question relates directly to each required field in the pkginfo file; as such direction is given on the correct values to be entered and input validation is performed. Where appropriate default answers are given.

  This results in a pkginfo file with the following variables set within it:

  PKG
  ARCH
  VERSION
  BASEDIR
  NAME
  CATEGORY
  DESC
  VENDOR
  CLASSES
  PSTAMP
  EMAIL
  

  Please see the pkginfo(4) manual page for a description of the above variables.

• If the build directory (under the work directory) is empty then it is filled with the package contents. How this is performed depends on whether we're dealing with a perl module or not.

  • If we're dealing with a perl module then we just pull in the relevent files from the blib directory.
  • If we are not dealing with a perl module then we call on chroot-install to perform the installation for us.

• We create the prototype file. This is performed by scanning the build directory. Any control files in the work directory (InstallPackage by default) will also be taken into account.

  Hand crafted prototype entries can be added by placing them in a file called ExtraPrototype in the work directory.

• We call template-control to process any package control script templates.

• We create the package in the directory spool format by using the pkgmk command supplied with Solaris.

• We transfer the package from the directory spool format into the datastream format. This is performed as it is this author's opinion that it is easier to deal with the single datastream file than dealing with the gaggle of directories and files in the directory spool format.

  This transfer is performed by using the pkgtrans command supplied with Solaris.

• Finally we remove the directory spool format version of the package. This action can be stopped by using the -l option

At the end of the above the package will be in the work directory as a single file. With the default options you will see, relative to the current working directory, the following file:

InstallPackage/%PKG%-v%VERSION%-%ARCH%.pkg

Where the values surrounded by % signs are macros set for the current package. Thus if the package has a name of SomePackage, with a version of 1.0.2 and was built in the SPARC architecture then the name would be:

InstallPackage/SomePackage-v1.0.2-sparc.pkg

This package is suitable for adding to a system by using the following command line:

#pkgadd -d InstallPackage/SomePackage-v1.0.2-sparc.pkg

Note that to run pkgadd you have to be the root user.

[Top] [Manual page]

chroot-install

chroot-install builds and environment suitable for installation of software within a chroot()ed environment by doing the following:

• Set the environment variable IN_CHROOT_INSTALL to the value of "yes" so that scripts et al can tell if they are being run within a chroot-install provided environment.
• Ensure that it is running as the root user so that the chroot() can be performed. If the script is not running as the root user then it will gain root privilages by the use of su.
• Work out the operation system and release you are running on and if it is supported.
• Build the chroot() environment as required. This can involve:
  • Creating devices
  • Copying directories
  • Making certain files available, i.e. /usr/lib/ld.so.1, via loopback mounts i.e. using the lofs file system.
  • Copy the the current working directory into the same location within the chroot() jail so that it appears as though you are within the same directory before and after the chroot() has occured.
  • Setting environment variables
• Setting the file creation mask (i.e. the umask) to 022 so that files and directories are created with sane permissions.
• Run either a given command or drop you into a shell which is running in the chroot() environment.
• Remove the chroot() environment, only leave behind the files which have been installed or changed by the commands run within it.

Whilst this may appear to be a large amount of work the result is that it appears to the installation process occuring within the chroot() jail that it has access to the entire system can do what it wants.

This is due to chroot() changing the root directory of the process which calls the chroot() system call. Every process has a pointer to the physical directory the root file system, or / resides on. This pointer is used in all file handling operations where the system is called upon to find the location of /. Thus to open the file /somefile the system will do something similar to the following:

• Open the directory pointed to by the root file system pointer for the process
• Search the directory for the name somefile
• If somefile exists then get its inode, open it and then return back the open file handle.

This means that if the pointer for / in a process is changed to a different directory then the entire world view of the process will be changed.

This is what the chroot() system call does.

Due to this world view change, a working environment has to be built for the chroot()ed process as essential system files will not be present within the new world view the process has.

So if the following lines of code were executed:

chdir("/some/directory");
chroot("/some/directory");

Then the root directory for the calling process would stop being / and start being /some/directory. Effectively this would mean that chdir("/") would actually take you to /some/directory.

This does cause some problems as there are files which are essential to the sane running of the system. For example if you wanted to run the most basic shell, /bin/sh in a chroot()ed environment, you'd have to provide at least the following inside the directory the process was going to be chroot()ed to:

• /bin/sh
• /usr/ld.so.1
• /dev/zero
• /usr/lib/libc.so.1
• /usr/lib/libdl.so.1
• /usr/lib/libw.so.1
• /usr/lib/libintl.so.1

[Top] [Manual page]