Each time you get a package from the links above, you perform a
number of steps which are in most cases the same:
For each application or package, this needs to be done. It would
be helpful to have a script which performs these actions by itself
just indicating which package is needed. The script getpkgs streamlines this
process. Download it in a proper location. There may also be a HINTS.TXT file which may indicate
manual actions to be done (see below).
The script is written with the smallest set of requirements. In
essence, it only needs a standard Slackware installation and even
in this case the script requires only (part of) following package
There is no requirement for X and others to run it, but most
packages themselves depend on graphical stuff, so you will
probably need a default installation in most cases anyway. The
script itself can be run from a command line. It is written as a
bash script using mostly standard tools sed, awk, ...
Nevertheless, to successfully run this script, following
requirements need to be taken into account:
Note that, although the script itself needs nothing else, several packages require other sets, so, in general, do install all standard package sets.
VERSION is specified by /etc/slackware-version
MACHINE is specified by uname -m, modified as is done in the slackbuild scripts
After a time it ends with:
Slackware package /tmp/dosbox-0.74-i486-2_SBo.tgz created.
Verifying package dosbox-0.74-i486-2_SBo.tgz.
Installing package dosbox-0.74-i486-2_SBo.tgz:
# DOSbox (DOS emulator/virtual machine for X11 and Unix)
# It allows you to play many of the old games you grew up loving, as
# well as many apps designed to run on DOS.
Executing install script for dosbox-0.74-i486-2_SBo.tgz.
Package dosbox-0.74-i486-2_SBo.tgz installed.
You can now test the package with the relevant command:
DOSBox version 0.74
Copyright 2002-2010 DOSBox Team, published under GNU GPL.
CONFIG:Loading primary settings from config file /home/local/localuser/.dosbox/dosbox-0.74.conf
MIXER:Got different values from SDL: freq 44100, blocksize 940
ALSA:Can't subscribe to MIDI port (65:0) nor (17:0)
#,REQUIRES,This is a message you may want to display always even before trying to download something #,DOWNLOAD,Additional download instructions for instance howto get a URL #,BUILD,Before building you may correct the options if needed #,INSTALL,Installation may require specific settings like creating a group with groupadd -g 215 GROUPNAME #,NOSUDO,Indicates that you have to start getpkgs as root on a local filesystem if not it won't build #,VERSION,If $PACKAGE.info version has been updated without updating SLACBUILDS.TXT #,POSTINSTALL,When this package is used as dependency for others you may need to perform this action #,OPTIONALPACKAGES,You can add a space separated list of packages which should be treated as needed dependencies
An empty line or a line starting with a # is ignored.
As an example get jdk when the HINTS.TXT file contains the line,
jdk,DOWNLOAD,\nhttp://www.oracle.com/technetwork/java/javase/downloads/jdk7u-downloads.html\nrunning with this hint:
Sometimes it is not obvious how a package is named. Manually
browsing through the SBo site or SLACKBUILDS.TXT file requires
some effort. For instance, to find a possible match for the 7zip
j7z: j7z version 1.1.0 in /misc/j7z
p7zip: p7zip version 9.20.1 in /system/p7zip
Several other related scripts can be found in my collection
getpkgs - a script for collecting Slackbuilds.org packagesSYNOPSIS
getpkgs [OPTION] ... PACKAGENAME [ROOTNAME]
The script performs an installation of a slackbuild script. It downloads the SLACKBUILDS.TXT description file from http://slackbuilds.org, downloads the slackbuild script, downloads the sources, build the sources and installs the package. If the slackbuild info file specifies REQUIRES, it can handle these additional packages as well.OPTIONS
Abort on the first error found. Normally, the script continues in most cases even when errors are encountered. This way, it tries to do as much as possible in advance. For instance, if downloading of one package fails, it may still be possible to continue with others anyway. However, in some cases, it may be useful to abort immediately. For instance when debugging an installation. With the -a option specified, the script will check at critical places and stop there.
Build downloaded sources. If they are not available in the ./srcs subdirectory, they are not downloaded and the script aborts when -a is specified or continues with its dependencies when -r is specified.
Do not show dialogs or do not wait for user interaction. When manual interventions are needed, they can be specified in the HINTS.TXT file. The script will check the HINTS.TXT for specific actions and normally stop and allow you to execute them. When option -c is specified, the script will ignore this information and continue. This can be used for instance when this script is used in another and let it continuing without user intervention. For instance if you have a list of packages and you want to download them in background.
Do not install or build the final package, only the dependencies, which requires -r to be specified as well.
List all the root packages from the srcs folder. A root package is one which is not used as a dependency for others. Rebuilding all the root packages will automatically rebuild all the packages. This option only checks the already downloaded srcs, not the ones in the SLACKBUILDS.txt as it would require downloading all the slackbuild scripts available. This script will also take a long time to run, especially on larger sets.
The name of the slackbuilds description file, the default is SLACKBUILDS.TXT as it is used on http://slackbuilds.org
Group the installation dependencies per package. This results in all the build packages which are needed as dependencies to be added and collected to a dedicated subfolder in ./pkgs/$VERSION/$MACHINE/$PACKAGE. For instance, eclipse requires jdk as well. If eclipse is built with the option -g, then there will be a dedicated subfolder eclipse containing both eclipse-*.tgz and jdk-*.tgz. This makes it easier to install an application as all the required dependencies are immediately found in the same directory. On the other hand, it results in some libraries found in several locations. When also option -r is specified, the script will run all dependencies with an additional ROOTNAME command line appended. This will have as result that the scripts can find the original location where all the dependencies should be placed. The ROOTNAME can also be used manually if you want to add a package yourself in this location.
Group source dependencies per package, this has the same effect as -g only for collecting the sources. Note that the sources do not use a machine specific subfolder.
Show help and a list of options
Dryrun, parse dependencies but do nothing else. The option -H will automatically set -r as well. This requires that the Slackbuild script is available, so this one will be downloaded if needed, but not the sources. If dependencies are found in the info, they will be checked in turn as well. So a whole chain of slackbuild scripts downloads can be triggered. As only the slackbuilds are downloaded and nothing else is done, it gives a fast, tree like overview of all the packages that are implied (dependencies). It will also check if manual interventions are required and note them as well.
Only install the built packages. They are looked for in the ./pkgs subfolder.
The location where the slackbuilds are fetched from. The default is http://slackbuilds.org/slackbuilds/$VERSION. From this place, the description SLACKBUILDS.TXT and all slackbuild scripts are downloaded.
Use directory as output directory. All files are saved in this location. If not specified, the current directory is used.
Query for possible matching packages in SLACKBUILDS.TXT (case insensitive). If SLACKBUILDS.TXT is not available, it is downloaded first. The search is performed with a grep -i, so all partial case insensitive matches are validated. The output contains an exact name to be used and the version as found in the descriptions.
Recursive operation. This processes the dependencies specified in REQUIRES field as well. If a package indicates another one in this field a new ./getpkgs script is started with the dependent one as parameter. The dependent package is handled before the parent. This guarantees that the sources are downloaded built and installed before the parent package is handled. The same actions are performed as for the parent. Thus if only -s (download sources) is specified, then the dependent package will only get its sources. If -g or -G is specified, then all the dependent packages are grouped together in the originating root package, even if they are detected several layers deeper. Thus a grand (grand...) -child ends up there as well. An exception is done when option -d is specified. In this case all dependencies are fully downloaded built and installed, but the original root package has only its sources downloaded. Note that some care has to be taken as circular dependencies will end in an endless loop until system shell resources are exhausted. This is also valid for the OPTIONALPACKAGES specification in the HINTS.TXT.
Only download sources as specified in the info file. Note that specifying this option will download both the slackbuild and the actual sources.
Update the SLACKBUILD descriptions. The existing one is moved to an archive subfolder with a timestamp appended. A new description is downloaded from http://slackbuilds.org or the location if specified with -L.
Specify user for extracting Slackbuild tar files. In general, when a tar file is extracted, it honors the user as specified during the creation of the tar file. This could result in a problem if this user is not allowed. For instance on a shared NFS file system with all_squash where it is not possible to change ownership of the tar file, this would result in an error (the file will be created though). To avoid this error, the proper user can be specified.
Update the package sources. The update is detected by comparing the version in the descriptions with the version in the slackbuild.info file. Note that if the version is overwritten in the HINTS.TXT file, this will cause still the original version to be installed. A message will be shown however. The option -u has the same effect as -s except that the existing sources are moved to the archive subdirectory with a timestamp appended. The original built binary in the ./pkgs subdirectory will be moved to this archive as well under an $ARCH subdirectory. If the option -g is also specified, all the built binaries (thus also the other dependencies if they exist) are moved as well. If -r is specified, all its dependent packages will have its sources updated as well. They will also get the same timestamp in the archive.
Update all package sources. For every package found in the ./srcs, a check is performed to see if the version is different from the SLACKBUILDS.TXT. If so, the existing one is moved to the archive, and a new one is downloaded. Note the all packages in the archive get the same timestamp, even if they are not related. Also, note that if option -G is used, this has no effect.
Show additional information
Uninstall package. When option -r (recursive) is specified, all dependencies are removed as well. Use option -r with caution as there is no checking if the dependencies are still used by other packages. Removing these might break other applications.
The same as option -x but this removes also all other versions. For instance, if a package was installed and then later updated with a new version, both will be present in the system. Using X in stead of x, both will be removed, not just the current. This applies to -r as well.
-Y:The script also uses some internal options. They can be specified, but it is not supposed to be used manually. They are used by the script itself:
Remove builds of installed packages (requires x or X)-Z:
Remove sources of installed packages (requires x or X)
Set the timestamp. This option is used to collect all items in the archive with the same timestamp. The timestamp is created using date +%Y%j%H%M%S and it is handled over from parent to child if needed. On a sidenote, the script has only second time resolution. This implies that only one script might be started at the same time if it is using the timestamp (-u option). The reason is that, if more then one script is running with the same timestamp, even if the specified package is different, it may trigger the same change, or move of the same directories when recursive (option -r) is also active. This could result in unexpected changes.
-R:The default selected options are 'sbi' which will just download build and install without checking for any requirements/dependencies. All files are saved in the current directory.
Set original shell level, this is used for 'pretty printing' of verbose messages and the dependency tree.