Here you can find what documentation is available for the current version of sbotools.
As sbotools is highly influenced by FreeBSD’s ports system and its pkgtools, the interface will be more or less familiar to anyone familiar with portupgrade, etc.
The first thing which needs to be done after installing sbotools is to pull a local copy of the SlackBuilds.org tree, minus the excess bits; this is optionally done automagickally at first run of sbofind(1), sboupgrade(1), or sboinstall(1), or manually via the sbosnap(1) command:
# sbosnap fetch
sboupgrade(1) and sboinstall(1) on 14.0, 14.1, or 14.2 will pull the list of requirements from a given slackbuild’s .info file, or on 13.37 will look at a given slackbuild’s README for a list of requirements and, if found, will check to see whether or not those requirements are already installed. For any not installed, sbotools will ask whether or not it should attempt to install it first. This is recursive so that ordering happens correctly. This functions correctly for -compat32 packages as well, and since a -compat32 is only somewhat useful without its 64-bit counterpart installed since the compat32 will have its headers stripped out, sbotools will offer to install the 64-bit version first if it’s not already installed. For various sanity reasons, if the -r flag is provided to bypass viewing the README, no requirement handling/parsing is done. Asking a tool to automatically do such things without reading the relevant README files is a bad, bad, bad idea.
When working with slackbuilds from the 14.0, 14.1, or 14.2 trees, sbotools will refuse to handle circular requirements. It will tell you as much, and ask if you want to continue, if it encounters any. Note that circular requirements do not always constitute bugs in the slackbuilds, since the REQUIRES field in the .info files includes both build-time and run-time requirements. As always, the user is expected to read and understand what s/he is doing and utilize the tools accordingly.
If there are useradd or groupadd commands in the README which need to be run prior to running a slackbuild, sboupgrade and sboinstall will ask if it should run those commands first. Depending on the format that they’re placed in the README, sbotools may occasionally fail to see them; as always again, the user is expected to read and understand and utilize the tools accordingly.
For slackbuilds with options documented in the README, of the form KEY=value, sboupgrade and sboinstall will provide an opportunity to set any options which one wishes to specify. This is yet another area where parsing mishaps may occur… as always yet again, read, understand, utilize accordingly.
Items which are unique to sbotools compared to FreeBSD’s pkgtools are sbofind(1) and sboconfig(1). sbofind(1) followed by a search term is approximately equivalent to running the following on a FreeBSD system:
# cd /usr/ports
# make search name="search_term" display=name,path
sbofind includes options to display the contents of the .info file and to display the contents of the README file for any slackbuilds it finds.
sboconfig(1) is a tool to manage sbotools.conf(5), the sbotools configuration file. It can also be edited manually; please read the man page before doing so. One thing to note is that the location of the SlackBuilds.org tree can be changed from the default, which is /usr/sbo, to any other location via the sboconfig(1) command, or by editing the sbotools.conf(5) file.
The sbotools 2.0 release also enables you to work with different versions of the SlackBuilds.org repository, but this should be used with care as other trees are not guaranteed to work on your current slackware version, nor will the sbotools 2.0 dependency resolution work on really old versions of the SlackBuilds.org tree. That's what the 0.x sbotools branch is for. This can also be done via the sboconfig(1) command, or by editing the sbotools.conf(5) file.
Another special mention from the 2.0 release is the addition of the so-called "local overrides", which will allow you to have a local tree of slackbuilds which overrides what's on SlackBuilds.org. It can be either in the form of simply changing a small bit of an existing slackbuild, or even making a completely new one available only locally to yourself. As usual, this can be done via the sboconfig(1) command, or by editing the sbotools.conf(5) file.