Getting packages
ref. http://slackbuilds.org/
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:
- verify which packages are needed as requirements
(dependencies)
- download the sources to proper locations
- launch the build script to compile the sources
- install the built packages
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
- A: you need Linux
- AP: some packages can be handled as sudo user
- D: compilation and build tools
- L: additional libraries
- N: you need to get several files from the network
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:
- It works with a standard Slackware installation (It has been
tested with versions 13.37 (32 bit), 14.0 (32 and 64 bit) and
14.1 (32, 64 bit and arm)
- You need to run it as root although it supports sudo and a
user who can sudo without password. Some packages can be handled
as sudo user, some can not and insist you be root.
- Verify proper ftp and http access. Especially ftp may require
some attention if you are behind a firewall. If needed, the
script supports the environment variables http_proxy,
https_proxy and ftp_proxy
- You must run it from a local account (root or sudo user, not
NIS) on a local filespace (not NFS, cifs,...). One of the
reasons is that root may not have access on remote file systems.
In the case where you want to maintain/install several hosts, a
network location may be useful. To set this up, you can provide
an NFS share with the options rw,subtree_check,all_squash,anonuid=1001,anongid=100
but note that this is a potential security leak. The
anonuid and anongid are "proper" user and group ids on the NFS
server. An SMB or CIFS will never work as it does not
provide proper permission attributes.
- Provide ample /tmp space for building the sources
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:
- cache: contains all downloaded files as is. It is itself split
in two subdirectories. One for the slackbuilds and one for the
files to build. The actual sources.
- srcs/$VERSION/[$PACKAGE]: This contains the extracted
slackbuild file contents and the downloaded sources.
- blds/$VERSION/$MACHINE/[$PACKAGE]: This contains the
slackbuild generated packages
- pkgs/$VERSION/$MACHINE/[$PACKAGE]: This contains links to the
install-able packages
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:
- download the SLACKBUILDS.TXT which contains the description of
all the packages. It is conveniently renamed to
SLACKBUIKDS-$VERSION.TXT
- download the slackbuilds. They are placed in
cache/slackbuilds. The directory structure is duplicated from
the original website
- 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
- 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.
- for packages needing dependencies, links are placed in the
pkgs directory, if they are grouped.
- 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 groups. 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
- the name of the package
- 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
- 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