summaryrefslogblamecommitdiffstats
path: root/source/d/slacktrack/slacktrack-project/docs/RELEASE_NOTES
blob: 02876d8986dbd1cd19d1acab66a372571cadeb6b (plain) (tree)








































































































































                                                                                     
slacktrack version 2.00
Release notes: 17th September 2008
===================================

Highlights:
-----------

slacktrack no longer uses 'installwatch' to track the installation
process -- what was previously called 'altertrack' has been turned
into 'slacktrack'.

slacktrack's method of tracking package installations is to
have the package installed directly onto the host's filesystem.

This is for a number of reasons:

 1.  installwatch is ill maintained and was failing to work correctly
     with new versions of glibc and GNU 'coreutils'.

 2.  installwatch could not track statically compiled binaries, 
     meaning that if a statically compiled binary was used to
     manipulate the filesystem in any way, these manipulations would
     not be reflected in your package contents.

 3.  With virtualisation -- QEMU, VMWare, SUN's VirtualBox -- being so
     readily available, and allowing filesystem 'snapshots', it's
     easier and easier to spin up a development operating system and
     build and install directly onto the root filesystem, thus getting
     a complete package.

Upgrading your build scripts from slacktrack version 1.x
--------------------------------------------------------

1.  slacktrack internal variables
    -----------------------------

    $SLACKTRACKFAKEROOT

    This variable points to the location of the package's
    root filesystem (usually /var/tmp/<someplace>).
    Using slacktrack 1.x, you could perform operations on the 
    package contents from your build script *during* the build
    process.

    In slacktrack 2.x, the package root directory is only populated
    after the build script has finished.

    However, the variable can still be used from a post-build
    script.  
    You can use slacktrack's '-R' operator to specify a post-build
    script.  In the example below, the post build script is
    called 'postbuildfixes.sh' and resides in the same directory
    as the 'trackbuild' script.

 **  Note: Ensure that your post-build script is chmod 755. **

# Launch the build script:
altertrack \
   --notidy \
   --showdeps \
   -T $TMP \
   -l $CWD/build.$ARCH.log \
   -R $CWD/postbuildfixes.sh \
   -b $PKGSTORE \
   -zIKASmg \
   -Ocp $PKGNAM-$PKGVERSION-$ARCH-$BUILD.tgz ./linuxdoc-tools.build

   The contents of this post build script can be something such as:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/bin/bash

# Once altertrack has determined what the contents of the package
# should be, it copies them into $SLACKTRACKFAKEROOT
# From here we can make modifications to the package's contents
# immediately prior to the invocation of makepkg: altertrack will
# do nothing else with the contents of the package after the execution
# of this script.

# If you modify anything here, be careful *not* to include the full
# path name - only use relative paths (ie rm usr/bin/foo *not* rm /usr/bin/foo).

# Enter the package's contents:
cd $SLACKTRACKFAKEROOT

# OpenSP creates this symlink; we delete it.
if [ -L usr/share/doc ]; then
   rm -f usr/share/doc
fi

# Incase you had CUPS running:
rm -rf etc/cups etc/printcap
# crond:
rm -rf var/spool/cron
rmdir var/spool

# perllocal.pod files don't belong in packages.
# SGMLSPL creates this:
find . -name perllocal.pod -print0 | xargs -0 rm -f

# Some doc dirs have attracted setuid.
# We don't need setuid for anything in this package:
chmod -R a-s .
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


2.  Build script changes
    --------------------

    If your build scripts were more sophisticated and took advantage of
    the way installwatch used a pseudo root filesystem, please be acutely
    aware that your build script now runs on the host's live operating system;
    so you need to be more careful.  However, as suggested -- run only on development
    installations.

3.  Additional files creeping into the packages
    -------------------------------------------

    Due to some daemons making changes to their config files whilst your build
    is in flight, you may find some additional files have crept into your package
    which you were not expecting.

    You may wish to turn off the following daemons before starting a build:
    CUPS
    crond
    sendmail
    ypbind (NIS)
    ypserv (NIS)

    If you look at the example post build script above, you can see that it
    removes some CUPS and crond residue.
    Whilst it would be possible to remove these paths from slacktrack's scan
    locations, some users may wish their package to place data in those directories;
    so you need to make your own adjustments and checks for this.


END.