Getting packages

Slackbuilds

ref. http://slackbuilds.org/

Slackware Alien builds

http://www.slackware.com/~alien/slackbuilds/

Automation

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).

You should never download a script and run it -especially as root or even sudo- unless you have carefully inspected it and understand what it does.

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 sets

There is no requirement for X and others to run it, but packages themselves may 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.

The script

The script getpkgs creates several subfolders:

VERSION is specified by /etc/slackware-version
MACHINE is specified by uname -m, modified as is done in the slackbuild scripts

The script runs in several stages:
  1. download the SLACKBUILDS.TXT which contains the description of all the packages. It is conveniently renamed to SLACKBUIKDS-$VERSION.TXT
  2. download the slackbuilds. They are placed in cache/slackbuilds. The directory structure is duplicated from the original website
  3. download sources: All the source files needed for the slackbuilds are downloaded from the internet and extracted. They are placed in the cache/repository subdirectory
  4. build sources: In this stage, the files retrieved from previous steps are built using the $PACKAGE.Slackbuild script. The results end up where Slackbuild decides, but it is expected to be found in /tmp. The result ends up in the blds subdirectory.
  5. for packages needing dependencies, links are placed in the pkgs directory, if they are grouped.
  6. install binaries: In this stage, the $PACKAGE....tgz is searched for in the /tmp, copied to the pkgs folder and installed.
When the script is run it checks what has been done so far, and does not redo completed tasks. Different Stages can be run separately by adding the options -s, -b or -i as additional parameter. For instance, only getting all the required sources can be done by:

localuser@bellatrix:~/Development$ ./getpkgs -s dosbox

As an example, running without the option -s gives

localuser@bellatrix:~/Development$ ./getpkgs dosbox

[...]
--2013-04-23 20:35:13--  http://surfnet.dl.sourceforge.net/project/dosbox/dosbox/0.74/dosbox-0.74.tar.gz
Connecting to 192.168.1.24:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 1265711 (1.2M) [application/x-gzip]
Saving to: 'dosbox-0.74.tar.gz'

100%[======================================================================================================>] 1,265,711    257KB/s   in 4.8s  

2013-04-23 20:35:20 (257 KB/s) - 'dosbox-0.74.tar.gz' saved [1265711/1265711]

dosbox-0.74/
dosbox-0.74/acinclude.m4
dosbox-0.74/config.sub
dosbox-0.74/AUTHORS
dosbox-0.74/configure
dosbox-0.74/missing
dosbox-0.74/ChangeLog
dosbox-0.74/visualc_net/
dosbox-0.74/visualc_net/dosbox.sln
...

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:
PACKAGE DESCRIPTION:
# 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.

localuser@bellatrix:~/Development$

You can now test the package with the relevant command:

localuser@bellatrix:~/Development$ which dosbox
/usr/bin/dosbox
localuser@
bellatrix:~/Development$ dosbox
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)
MIDI:Opened device:oss

And a dosbox appears:



Solving dependencies and other options

Often packages rely on others to be available before they can be successfully run or even built and installed. As indicated, this requires digging trough the info and slackbuilds site to get the needed material. The getpkgs script can perform these operations by itself. As an example, aMule requires cryptopp and wxPython. To get everything downloaded, built and installed at once, add the option r (recursive):

localuser@bellatrix:~/Development$ ./getpkgs -r aMule

After a while, you have aMule ready

localuser@bellatrix:~/Development$ amule

giving the aMule configuration popup:




Note: The script relies on the information in the SLACKBUILDS.TXT and slackbuild scripts. But even then it might fail due to other reasons, for instance sources which are hidden behind all kind of forms etc. In this case, actions to correct the problems can be done manually after which the script can be restarted.

Note: The script does not set "interesting" properties as they are made available in several places. All is kept configured default.

Note: several packages requires additional actions as creating users and group
s. This must always be done manually.

Following a list of options:

localuser@bellatrix:~/Development$ ./getpkgs -h

usage: getpkgs [options] package [rootname]
Getting slackbuild packages (http://slackbuilds.org)

  a:  abort on first error found, otherwise keep continuing
  b:  only build downloaded sources
  c:  do not show dialogs or do not wait for user interaction
  C:  allow insecure downloads
  d:  do not install or build final package, only dependencies (requires r)
  D:  list all root packages (which do not serve as dependent ones)
  E location: retrieve sources from location regardless of info (a local cache perhaps)
  f file:  slackbuilds description file, default SLACKBUILDS-14.1.TXT
  g:  group installation dependencies per package
  G:  group source dependencies per package
  h:  show this help
  H:  Dryrun, parse dependencies but do nothing
  i:  only install built packages
  I:  ignore version differences
  L location:  Slackware location, default = http://slackbuilds.org/slackbuilds/(version)
  M:  allow incorrect md5 sums
  o directory: Use directory as output directory
  q:  query for possible matching packages (case insensitive)
  r:  recursive, process dependencies specified in REQUIRES field as well
  R version:  slackware version to be used, but does not change -f option
  s:  only download sources
  S:  update SLACKBUILD descriptions
  t user:  Specify user for extracting Slackbuild tar files
  u:  update package sources (and its dependencies if -r specified)
  U:  update all package sources
  v:  Show additional information
  V:  Show settings
  x:  remove installed package(s, when recursive)
  X:  remove all versions of installed package(s when recursive)
  Y:  remove builds of installed packages (requires x or X)
  Z:  remove sources of installed packages (requires x or X)

Example: getpkgs -gr vlc

Sometimes, it is useful to collect all dependencies for a package. This can be achieved by specifying the -g and -G options. -g Places all installable packages into a 'rootname' subfolder, -G all sources. If rootname is not specified, the first one before the dependencies are handled is taken as rootname.

The HINTS.TXT file

When a file HINTS.TXT is available, getpkgs uses this to message manual actions. These actions are sometimes needed as, otherwise a successful package can not be built. Hints may be specific download instructions, but also specific changes to be made to the system. When a HINT is detected, the script will stop and allow you to perform the manual actions before continuing. In case of the DOWNLOAD hint, the script will not stop if the needed files are already present.

Each line in this file is composed of a comma separated entry of which
  1. the name of the package
  2. the instruction
    #,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
    #,BUILDENVIRONMENT,Environment variables you can set before running the slackbuild
    #,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
    #,NOARCH,architecture on which it is not supported (there can be only one) and only needed when not specified in .info
    #,OPTIONALPACKAGES,You can add a space separated list of packages which should be treated as needed dependencies
    
  3. informative text shown in the dialog, or additional info for the getpkgs script

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\n
running with this hint:

localuser@aldebaran:/home/shared/installation/packman/test$ ./getpkgs jdk
Getting jdk from http://slackbuilds.org/slackbuilds/14.0/development/jdk.tar.gz
wget -v -nd http://slackbuilds.org/slackbuilds/14.0/development/jdk.tar.gz --proxy-user= --proxy-password=
--2013-11-06 23:55:47--  http://slackbuilds.org/slackbuilds/14.0/development/jdk.tar.gz
Connecting to 192.168.1.24:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 3516 (3.4K) [application/x-gzip]
Saving to: 'jdk.tar.gz'

100%[=====================================================================================>] 3,516       --.-K/s   in 0s     

2013-11-06 23:55:48 (588 MB/s) - 'jdk.tar.gz' saved [3516/3516]

jdk/
jdk/slack-desc
jdk/README
jdk/jdk.SlackBuild
jdk/profile.d/
jdk/profile.d/jdk.sh
jdk/profile.d/jdk.csh
jdk/jdk.info

Now following dialog appears:



Finding and querying

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 compressor:

localuser@aldebaran:/home/shared/installation/packman/ins$ ./getpkgs -q 7z
j7z: j7z version 1.1.0 in /misc/j7z
p7zip: p7zip version 9.20.1 in /system/p7zip
localuser@aldebaran:/home/shared/installation/packman/ins$

Options overview, manpage

You can find some more information in the manpage.

Fake package names as placeholders

When getpkgs handles dependencies, it does this by recursively calling itself with a rootname as additional commandline item. For instance, in the previous example of aMule, which needed wxPython, somewhere during the execution, a child script is started with the same options but with two names on the commandline. In this case, the command:

localuser@bellatrix:~/Development$ ./getpkgs -rg aMule

triggers the execution of

localuser@bellatrix:~/Development$ ./getpkgs -rg wxPython aMule

This is, as soon as the slackbuilds info is retrieved, the dependency is handled in a child process. For this child process, getpkgs only needs aMule as the name of the folder where the results have to be placed or grouped. Option -g is essential here. When the dependency has been completed, the parent process continues as before. This can be used as trick to create a collection of needed software. You can start the first instance of getpkgs with an additional command line item, and this does not have to be a real package, as it is only used for the name of the directory where the result goes. You can create your own set for different systems by omitting the installation.

For instance, the command

localuser@bellatrix:~/Development$ ./getpkgs -rgsb dosbox my_desktop

creates following files in blds and pkgs:
.
|-- blds
|   `-- 14.1
|       `-- x86_64
|           `-- dosbox-0.74-x86_64-2_SBo.tgz
|-- pkgs
|   `-- 14.1
|       `-- x86_64
|           `-- my_desktop
|               `-- dosbox-0.74-x86_64-2_SBo.tgz -> ../../../../blds/14.1/x86_64/dosbox-0.74-x86_64-2_SBo.tgz

As can be seen, there is a subdirectory my_desktop which holds the dosbox package. By adding more commands like:

localuser@bellatrix:~/Development$ ./getpkgs -rgsb leafpad my_desktop

You can fill this directory with the software you need on this system.

A final comment is that you can create the same result by adding dependencies in HINTS.TXT as well, but in this case, the first package must be a real one. For instance, a line
icewm,OPTIONALPACKAGES,dosbox leafpad
in HINTS.TXT and running

localuser@bellatrix:~/Development$ ./getpkgs -rgsb icewm my_desktop

creates the subdirectory my_desktop with the 3 packages, but it is confusing to indicate that leafpad and dosbox are needed for icewm. So it is better to create a small textfile for each system with the names of all the packages and use the getpkgs script multiple times.

Creating a local repository

If you have to install a large number of systems, you don't want to download, each time on each of the systems. For this you can setup a local website. It is sufficient to copy the cache directory SLACKBUILDS and HINTS file. Using both options -E and -L will provide the proper local information. Note that this also allows to create your own sets of packages.



K. E. Venken - Hoboken (BE) - 2013