Package management

Since T2 is build from source, you have two orthogonal and nicely integrated methods to install or update package: using a prepared binary package or build the package from source.

Package meta-data

Using the same T2 source revision there is no recognizable difference between a binary package and one built from source. The meta-data state stored in /var/adm is exactly the same and the installation methods can - of course - be intermixed as needed. Information are stored in ordinary, per package text files and grouped into sub-directories as following:

  • cache: the time the last build took, resulting files count, size and dependencies

  • cksums: the package's files Unix checksum

  • dependencies: the detected build-time dependencies

  • descs: a copy of the package's .desc file without newlines

  • flists: the files installed by the packages

  • md5sums: the new-style package's files md4 checksum

  • packages: a human readable pretty print of the package description and build-time metrics

  • parse-config: shell scripts included during the build allowing installed packages to influence and configure the build of packagesy

For the packages built from source there are additional informations available:

  • backup: the backup of files that have been detected to be modified

  • dep-debug: a list of utilized files and the associated dependency

  • logs: the full build output created during the build

  • olists: lists of files that have been in the package's file list but have not been reinstalled during a rebuild and thus could be considered obsolet / orphaned

Installing or Updating a Package From Source

Installing or updating a single package can be done using the regular automated build system using Build-Pkg or Emerge-Pkg, for example:

./t2 install package

This will build and install the package with its default configuration in the current system's root. Optionally a different root location can be specified with the argument '-root' or the argument '-update' can be used to let the Build-System backup e.g. modified configuration files and restore them after the build. Section the section called “Building a Single Package” includes more details about the two scripts.

Installing or Updating a Binary Package

The STONE utility also allows you to install/update or remove packages using the same GUI as used during the installation. The gasgui which is executed from within the STONE module uses the T2 mine.

If you want to manually extract files on a non-T2 system you might need to install mine manually:

tar xvf download/mirror/m/mine-$ver.tar.bz2
cd mine-ver
make USE_GAS=0

Just running mine prints the usual usage information.

To install a gem package, specify the argument '-i' to install the specified package. If you want to overwrite modified files - e.g. configuration files, specify the option '-f' (force).

mine -i package.gem

Removing a Package

To remove a package just use the mine with the argument '-r'. It does not matter whether the package was built from source or installed using mine since the two methods leave the same meta information in the /var/adm package files.

mine -r package

Another way is to use the information in /var/adm/flists directly, for example:

cat /var/adm/flists/package | cut -d ' ' -f 2 | xargs rm -f

Though you are advised to be very careful using this example, since e.g. your modified files are removed and if your system has evolved you might delete files you did not intend to delete!

Consistency Checking of an Installed Package

For maintenance or security reasons it might often be useful the check the system files for modifications. The mine has an option '-y' to check the checksum data in /var/adm/md5sum with the file present in the system. If no package is given all packages will be checked.

mine -y package
mine -y # no argument to check all packages

Also in this use case it is possible to use the /var/adm data manually:

cd /
md5sum --check /var/adm/md5sums/package | grep -v OK