swpkg - Software Packaging

• Basic documentation
• Step by step guide
• Migration guide
• Example: installing xxx
• Deprecated documentation covering the old set of swpkg tools.

Basic documentation of swpkg tools is found in manual pages. Please refer to the latest version as the following are provided for convenience and may slightly be out of date:

• swln: The main component of swpkg used to create/delete links.
• swb: The software builder.
• swinfo: Simple script to maintain info/dir files.
• swchk: Tool to maintain source and target directories.
• swreport: Inter package dependency reporting tool.

This section shows the process of building a fairly typical software application: qpage

• Step 1: initialize the build environment

  % mkdir /tmp/BUILD
  % cd /tmp/BUILD 
  % swb init qpage 3.3
  Looking for dependencies in Makefile
  Looking for dependencies in Makefile.in
  Looking for dependencies in configure
  Please review possible dependencies.
  Package unpacked under qpage-3.3
  

• Step 2: prepare the build.
  qpage is a pretty simple software which has no special dependencies. However, if you want to use a specific compiler built with the swpkg tools (as opposed to one supplied by your OS), you need to add it as a dependency. This is done using the following command.

  % swb edit deps
  

• Step 3: qpage customization
  qpage has a "poor" configure script and requires us to edit a file before building it. We do so, and record this fact with swb.

  % cd qpage-3.3 
  % vi config.input
  % swb mods diff config.input 
  config.input was modified.
  Adding dependency: gcc-4.1.2
  

• Step 4: Launch the build

  % swb -c ./configure --prefix=%prefix%
  % swb -c make
  % swb -c make install
  

• Step 5: Finalize the build
  Edit the (auto-generated) swb script to simplify future builds of this software.

  % swb edit script
  % swb end
  

• Step 6: Complete the installation
  swb does not yet handle finalizing permission changes, so do this manually from a root shell.

  # chown -hR 0:0 /usr/local/pkgs/qpage-3.3
  # swln qpage-3.3
  -- 1 package added
  

• Notes:
  • swb suppresses most output to the main window where commands are issues. However, the swb init command will by default open two additional X11 terminal where additional output is displayed. In any event, everything is fully logged by swb.
  • The above example shows what happens the first time a software package is built. A few extra and seemingly useless steps ensure that (1) the build is properly recorded and that (2) future builds will be easier (see below).

Now, following the above example, the same software can be built on a different architecture as shown below. Upgrading to a new version of the software offers similar benefits.

% mkdir /tmp/BUILD
% cd /tmp/BUILD
% swb init qpage 3.3
Found 1 previous sessions:
 > _3.3:0:SunOS:sparc                       2008-01-15 10:26 <11000>

Will learn from session '_3.3:0:SunOS:sparc',
you have 2 seconds to hit Control-C...

Looking for dependencies in Makefile
Looking for dependencies in Makefile.in
Looking for dependencies in configure
Package unpacked under qpage-3.3
Please review possible dependencies.
% swb edit deps     -- In this case, no actual edition is likely, just a review
% swb run
Adding dependency: gcc-4.1.2
patching file config.input
Script completed successfully, closing session.
# chown -hR 0:0 /usr/local/pkgs/qpage-3.3
# swln qpage-3.3
-- 1 package added

If you're lucky, you're building a collection of software packages from scratch, and have no existing base of installed software in /usr/local (or elsewhere). If this is the case, you can pretty much stop reading this already. On the other hand, if you live in the real world, you probably aren't that lucky and the following will help you.

It is important to realize that successfully migrating an environment to one setup using the swpkg philosophy and tools is no simple or quick task. For most people it will be a large project requiring a significant deal of effort and dedication. However, it is well worth it, and isn't one of these impossible to achieve goals. There are (at least) two ways you can go about it:

• If you can get significant resources allocated for this, then you can be fairly aggressive. Follow the guidelines below, come up with a plan and go for it. You can probably get 90% done fairly quickly and tackle the most tricky parts last. How long and painful this will be really depends on how chaotic your current environment is.
• If you have no real resources for this, then what you need above everything else is a champion dedicated to making this happen. Someone with a good understanding of the philosophy who will pull everyone else in the right direction.
  • First and foremost, document what you are trying to do and present it to relevant group.
  • Get approval or consensus on doing it, whichever is relevant to your environment. Make a new rule or policy saying that any new software installation MUST follow the new way.
  • Pick a few packages to upgrade (or even reinstall) so that people have examples to look at.
  • Let time be your ally. Most of the software that is really used will get upgraded soon or later.

No matter where your installed software resides, you should carefully consider where your target directory will be. While /usr/local is the default set for the swpkg tools, it is easy to override. And avoiding /usr/local is a good thing to prevent (too) smart "configure" type scripts from finding binaries, libraries are other dependencies in there. Be sure to read this section of the swpkg philosophy before making your decision.

Whether your target directory will be the same as where your existing software is or not brings two different approaches. Both are doable, although the former quite preferrable. However, in both cases, you will probably need to inventory (and identify) the already installed software packages. (This can be a daunting tasks as random files are often not easy to attribute to a software. Enlist the help of a senior UNIX admin if you have trouble with this.) This is the best way to get to have an idea of what you will need to install. It is also a good opportunity to decide on what you probably don't want to reinstall for things that are no longer used.

The rest of this only applies to the case where you use the same target directory.

By default, swln will NOT replace any file in order to create a link for a package. This is something that you will need to do as you reinstall existing software. Such behaviour is easy to override by using the -I flag to swln, and in most cases, you'll be fine. Things can of course break as other installed programs may depend on what you're just blowing away (and especially files that don't get linked in the target directory), but this is pretty much the same as if you were simply installing the new version the old fashioned way, directly in the target directory.

As time goes by, you have more and more links in your target directory, and less and less real files. However, unless you are a god, you probably will never be able to get rid of all such files simply by reinstalling packages. At some point, you will want to audit such remaining files, and blow them away as the final step (once you get over the likely surprises you will uncover during the audit).

© 2001-2008 - Christophe Kalt