Differences

This shows you the differences between two versions of the page.

--- pkg [2015/05/12 04:04]
slackermedia
+++ pkg [2021/06/03 19:48] (current)
@@ Line 1: / Line 1: @@
 ====== Understanding How Applications are Managed ======
-Forget everything (or most of) you knew about software installation from traditional desktops. This increasingly holds true regardless of OS, since other operating systems are moving toward managed installation like Linux has had for a decade, and everyone is moving toward contained installers.
+Forget [most] everything you knew about software installation from traditional desktops. This increasingly holds true regardless of OS, since other operating systems are moving toward managed installation like Linux has had for a decade, and everyone is moving toward contained installers.
 Whether you manage just one system or one hundred systems, it's important to understand how software is installed, un-installed, and upgraded on a Slackware system. Generically, this is referred to as "package management". For large scale installs, there is administrative software (such as [[https://puppetlabs.com|Puppet]]) but it's still important to understand how it all happens on an instance-by-instance basis.
@@ Line 31: / Line 32: @@
 Each of these offers a variety of choices for how a user manages the software on a computer; none of them impose update schedules, automatic dependency installation and removal, or demand a complex system of database calls be learned.
+===== Pre-Built Packages =====
-===== Slackware Packages =====
+<WRAP info>
+**Quickstart**
-The basic ''pkgtool'' suite is designed to help the user install, upgrade, and
+Install a Slackware package:
-remove //pre-built// Slackware packages.
+  -Find a Slackware package from a trusted site such as [[http://studioware.org]] or [[http://slackware.org.uk/people/alien/restricted_slackbuilds]] and download it //and its the md5 file, if available// to your computer.
+  -If an md5 sum was available, verify the authenticity of the package with ''md5sum /path/to/package | cut -f1 -d" " && cat /path/to/md5sum''
+  -Assuming the numbers match, open a terminal and type ''su -c "installpkg /path/to/package"'' to install.
+Remove a Slackware package:
+  -''su -c "removepkg /path/to/package"'' un-installs the application, but not your personal data relating to that application (nor any configuration files that have changed since having been installed).
+Look at the contents of a package:
+''tar -tvf /path/to/package | more''
+</WRAP>
+==== Package Tools ====
+The package tools that ship with Slackware are designed to help the user install, upgrade, and remove //pre-built// Slackware packages.
 Slackware packages are ordinary compressed tar files. They contain, quite
@@ Line 41: / Line 61: @@
 <WRAP alert>
-Slackware packages are generic archives, but not all ''.tgz'', ''.tbz'', and ''.txz'' are Slackware packages! Compressed tarballs are used to store all kinds of files, so just because you find a ''.t?z'' archive it doesn't mean that you can install it.
+Slackware packages are generic archives, but not all ''.tgz'', ''.tbz'', and ''.txz'' are Slackware packages! In other words, Slackware packages are a subset of archives; compressed tarballs are used to store all kinds of files, so just because you find a ''.t?z'' archive it doesn't mean that you can install it.
 Most Slackware packages follow a conventional naming scheme like ''appname-version-arch-tag.t?z'' (for example, ''planter-0.5.0-noarch-SMi.tgz'' is a Slackware package, while ''planter-master.tgz'' is not).
@@ Line 47: / Line 67: @@
 If you are ever unsure, use ''tar -tvf name-of-file.t?z'' to look into the archive without opening it.
 </WRAP>
 Those that are Slackware packages contain, generally speaking, these files:
-  * slack-desc
+  *slack-desc: A description of the application this package will install.
+  *doinst.sh: A shell script doing post-install tasks, like adding support in one program for the application just installed.
+  */usr, /usr/share, and other folders into which the executable application itself exists and from which it will be copied out into the rest of the system.
-    A description of the application this package will install.
+A traditional package, therefore, is a mimicry of your Linux system; it
+contains a few descriptive files or scripts to do a few specialized tasks, but
+mainly it is simply an isolated ''/usr'', ''/etc'', and whatever else is required for
+the application to run, with all the compiled files in place.
-  * doinst.sh
+When a Slackware package gets installed, all of these files are imposed over your existing system. Once the files are copied from the package to your system, you can run the application.
-    A shell script doing post-install tasks, like adding support in one program
+Slackware provides tools to automate all aspects of installing, tracking, and removing packages:
-    for the application just installed.
-  * /usr, /usr/share, and similar
+  *''installpkg'' installs and logs packages
+  *''upgradepkg'' upgrades packages and updates log entries
+  *''removepkg'' removes packages and package log entries
+  *''pkgtool'' a menu system for managing packages
-    The folders into which the executable application itself exists and from
-    which it will be copied out into the rest of the system.
-A traditional package, therefore, is a mimicry of your Linux system; it
-contains a few descriptive files or scripts to do a few specialized tasks, but
-mainly it is simply an isolated /usr, /etc, and whatever else is required for
-the application to run, with all the compiled files in place.
-The install process is to take all of these files and to superimpose them over
+''installpkg'' is a simple front-end to the process of decompressing, copying files
-your existing Linux system. In other words, you could literally go through each
+from, and logging the contents of a Slackware package.
-file in the package and copy it over to the corresponding folder on your
-computer; ie, cp package/usr/bin/foo /usr/bin/foo and so on. Once the files are
-copied from the package to your larger system, the application can be run on
-your computer.
-This would be tedious and impossible to track and therefore difficult to
+<code>
-reverse, so it would be smarter to have a shell script do it for you. The
+$ su -c 'installpkg /media/cdrom/extra/foo/foo-*.txz'
-scripts included on Slackware for these and related tasks are:
+</code>
-  * installpkg
+Once a package is installed, all of the files that have been placed on your system are noted in ''/var/log/packages''. You may see a list of every package currently installed on your system:
-  * removepkg
+<code>
+ls /var/log/packages | less
+</code>
-  * pkgtool
+You can also see every file contained in each one of those packages:
-The pkgtool, installpkg, and removepkg Utilities
+<code>
+less /var/log/packages/foo
+</code>
-installpkg is a simple front-end to the process of decompressing, copying files
+Using this information, two other scripts can upgrade packages, or remove packages.
-from, and keeping a record of a Slackware package.
-    $ su -c 'installpkg
+<code>
-        /media/cdrom/extra/foo/foo-*.txz'
+$ su -c 'upgradepkg /var/log/packages/foo-version.txz foo-newVersion.txz'
+$ su -c 'removepkg /var/log/packages/foo-version.txz'
+</code>
-Once a package is installed, all of the files that have been placed on your
-system are recorded in /var/log/packages. Using this information, two other
-scripts can upgrade packages, or remove packages.
-  $ su -c 'upgradepkg
+If you have a difficult time remembering commands, you can use ''pkgtool'', a graphical tool that runs in the terminal. Its use is fairly self-explanatory; choose whether you want to install packages from a directory, remove packages that are already installed, or view a list of installed files associated with a package.
-  /var/log/packages/foo-version.txz foo-newVersion.txz'
-  $ su -c 'removepkg
-  /var/log/packages/foo-version.txz'
-Tip
+{{ pkgtool.png }}
-To see exactly what is going to be installed before installing it, you can use
+Since Slackware itself uses Slackware packages to install itself in the first place, you can also run several initial install scripts again, should you need to re-configure.
-the pkgtool command, which provides a menu, including the option to view a list
-of all the files in the Slackware package.
-Most of these commands can be done with pkgtool. pkgtool is an empty shell that
-looks for Slackware packages in any directory defined by the user. Pkgtool is
-able to install a package, remove a package that has once been installed, and
-even upgrade packages. It is a graphical tool that runs in the terminal, so its
-use is fairly self-explanatory; simply choose whether you want to install
-packages from a directory, remove packages, or view a list of installed files
-associated with a package. Since Slackware itself uses Slackware packages to
-install itself in the first place, you can also run the initial install scripts
-again, including the font cache, lilo config, choose a default window manager,
-and more.
-Slackware Packages and slackpkg
+==== Slackpkg ====
 The first Slackware packages you'll deal with are the ones installed onto your
-system during the normal installation process. You probably won't interact with
+system during the normal installation process. You won't interact with these directly, but they are always available for re-installation, either from your install media or via the internet.
-these directly, but they are always available for reinstallation, either from
-your install media or via the internet.
-Aside from the default packages installed with a full install, there is an /
+Aside from the default packages installed with a full install, there is an ''/extra'' directory containing additional packages. To install them from the install DVD, use ''installpkg'':
-extra directory containing additional packages. To install them from the
-install DVD, use installpkg:
-  # installpkg /dev/cdrom/extra/foo-0.1.tgz
+<code>
+# installpkg /path/to/dvdrom/extra/foo-0.1.tgz
+</code>
+If you don't have the install media, use the internet.
-If you don't have the install media, then of course all of this is possible
+To install a package from the internet, you //could// download the ''.txz'' file from a
-from the internet.
+Slackware mirror and then use ''installpkg'' or ''pkgtool'', but there is a simple
+script that can make the process easier, called ''slackpkg''.
-To install a package from the internet, you could download the .tgz file from a
+To configure ''slackpkg'' so that it knows where to look online for packages, open
-Slackware mirror and then use installpkg or pkgtool, but there is a simple
+''/etc/slackpkg/mirrors'' (a text file) as root and find the mirror that is
-shell script that can make the process easier, called slackpkg.
+associated with your Slackware version and that is geographically close to you.
+Uncomment it by removing the leading hash mark.
-To configure slackpkg so that it knows where online to look for packages, open
+The list of mirrors offers both ftp and http access, but you must uncomment //only one//.
-/etc/slackpkg/mirrors (a text file) as root and find the mirror that is
-associated with your Slackware version and that is geographically close to you,
-and uncomment it. This list of mirrors offers ftp and http access, but you must
-uncomment only one.
-Note
+<WRAP tip>
+In terms of ''slackpkg'', there is no functional difference between ftp and http.
-In terms of slackpkg, there is no functional difference between ftp and http.
 If you use a network that restricts, for instance, ftp traffic, then http would
 have the obvious advantage for you.
+</WRAP>
-Using slackpkg is simple and much like using tools like yum or aptitude. You
+Update the list of available packages by issuing the initial command
-should update your list of available packages by issuing the initial command
+''slackpkg update''; this updates the //list// of packages on the server, it does not upgrade any of your software.
-slackpkg update and from that point on, the repository can be searched by using
-the command slackpkg search foobar as root, and an application can be installed
-with slackpkg install foo. As usual, reading the manual page for slackpkg will
-reveal a full listing of associated commands.
-Once a package has been installed with slackpkg, it can be removed or upgraded
+The repository can be searched by using the command ''slackpkg search foo'' as root, and an application can be installed with ''slackpkg install foo''. As usual, reading the manual page for ''slackpkg'' reveals a full listing of associated commands.
-using pkgtool and the other package management commands.
-Since a full install of Slackware contains nearly everything that slackpkg has
+Once a package has been installed with ''slackpkg'', it can be removed or upgraded
-access to anyway, the most common use for slackpkg in Slackermedia will be for
+using ''pkgtool'' and the other package management commands.
+Since a full install of Slackware contains nearly everything that ''slackpkg'' has
+access to anyway, the most common use for ''slackpkg'' in Slackermedia will be for
 security updates. You should perform a periodic update of slackpkg followed by
-  $ slackpkg upgrade-all
+<code>
+$ su -c 'slackpkg upgrade-all'
+</code>
-Look through the list of available updates, and update as you see fit. Only
+Look through the list of available updates, and update as you see fit.
+<WRAP important>
+Only
 essential security updates are distributed via slackpkg, so even in-production
 machines are safe to patch.
+</WRAP>
-Finding Additional Slackware Packages
+===== Finding Additional Packages =====
 If you installed the full Slackware install base, then the only additional
-packages that slackpkg provides are applications found in the /extra and /
+packages that slackpkg provides are applications found in the ''/extra'' and ''/
-testing directories (also available on your install disc). Aside from these
+testing'' directories (also available on your install disc). Aside from these
 directories, everything else on the server or disc has been installed on your
 system.
-Distributors of Slack Packages
+{{anchor:repo}}
+==== Distributors of Slack Packages ====
 Slackware packages can be found elsewhere online, but you should make sure you
@@ Line 191: / Line 194: @@
 A few reliable places with good reputations:
-Recommended Slack Package Distributors
+**Studioware**
-AlienBob
+<WRAP indent>
+[[http://studioware.org/packages]] is full of current builds of all kinds of multimedia tools. There are a wealth of new production toys to be discovered here, so it will probably take you a few days to explore and test what you find.
+</WRAP>
-    slackware.com/~alien/slackbuilds is a repository of useful applications,
+**AlienBob**
-    including Scribus, the OpenJDK Java dev kit and runtime, the Chromium web
-    browser, and the Opus audio codec. Not all of the applications he offers
-    are always terribly up-to-date, and some are, so take that into
-    consideration before deciding what you want to install from this server.
-    slackware.org.uk/people/alien/restricted_slackbuilds is a repository of
+<WRAP indent>
-    useful applications that include codecs or code that cannot be distributed
+[[http://slackware.com/~alien/slackbuilds]] is a repository of useful applications, including ''Scribus'', the ''OpenJDK'' Java dev kit and runtime, the ''Chromium'' web browser, and the ''Opus'' audio codec. Not all of the applications he offers are always terribly up-to-date, and some are, so take that into consideration before deciding what you want to install from this server.
-    on USA-based servers. Most notably this includes VLC and HandBrake. Not all
-    of the applications he offers are up-to-date, and some are, so take that
-    into consideration before deciding what you want to install from this
-    server.
-Slacky.eu
+[[http://slackware.org.uk/people/alien/restricted_slackbuilds]] is a repository of useful applications that include codecs or code that cannot be distributed on USA-based servers. Most notably this includes [[vlc|VLC]] and [[handbrake|HandBrake]]. Not all of the applications he offers are up-to-date, and some are, so take that into consideration before deciding what you want to install from this server.
+</WRAP>
-    slacky.eu is a long-standing and vibrant community of Slackware users in
+**Slacky.eu**
-    Italy. The site has both 32-bit and 64-bit repositories with useful
-    software spanning all categories.
-    Not all of the applications offered here are up-to-date, and some are, so
+<WRAP indent>
-    take that into consideration before deciding what you want to install from
+[[http://slacky.eu]] is a long-standing and vibrant community of Slackware users in Italy. The site has both 32-bit and 64-bit repositories with useful software spanning all categories.
-    this server.
+</WRAP>
-Slackermedia
+**Slackermedia**
-    slackermedia.info/slackbuilds offers useful (and some not-so-useful)
+<WRAP indent>
-    packages, including JSampler, butt audio streamer, and most importantly the
+[[http://slackermedia.info/slackbuilds]] offers useful (and some not-so-useful) packages, including JSampler, butt audio streamer, and most importantly the Slackermedia-approved, everything-plus-the-kitchen-sink compile of [[ffmpeg]].
-    Slackermedia-approved, everything-plus-the-kitchen-sink compile of ffmpeg.
-    Not everything is always up-to-date, but they are the versions of software
+Not everything is always up-to-date, but they are the versions of software that the author of Slackermedia is using.
-    that the author of Slackermedia is using.
+</WRAP>
-Studioware
-    studioware.org/packages is full of current builds of all kinds of
+==== rpm2tgz ====
-    multimedia tools. There are a wealth of new production toys to be
-    discovered here, so it will probably take you a few days to explore and
-    test what you find.
-    Not all of the applications offered here are up-to-date, and some are, so
+The command ''rpm2tgz'', which converts a pre-built package for [[http://redhat.com|Red Hat]] or [[https://getfedora.org|Fedora]] Linux into a ''slackpkg'' (ie, a ''.t?z'' file) that can then be installed via ''installpkg'' or ''pkgtool''. This is similar to finding a
-    take that into consideration before deciding what you want to install from
+pre-built ''.tgz'' on any given software's download page, except that rpm files are ubiquitous to Linux package formats and the likelihood of finding a ''.rpm'' file often exceeds the likelihood of happening across a Slackware package.
-    this server.
-rpm2tgz
+There are differences between how a Red Hat system is built and how Slackware is built, however, so there is some chance that the converted package will not work, but it's usually worth trying.
-A useful command that can be used in conjunction with pkgtool is rpm2tgz, which
+Reliable sites for RPM packages include:
-converts a pre-built package for Red Hat or Fedora Linux into a slackpkg (ie, a
-.tgz file) that can then be installed via pkgtool. This is similar to finding a
-pre-built .tgz on any given software's download page, except that rpm files are
-ubiquitous to Linux package formats and the likelihood of finding a .rpm file
-often exceeds the likelihood of happening across a Slackware package.
-Once you've downloaded the .rpm file, use rpm2tgz to convert it:
+  *[[http://rpmfusion.org]]
+  *[[http://ccrma.stanford.edu/planetccrma/software/]]
+  *Official Red Hat (and related) [[https://admin.fedoraproject.org/mirrormanager/|mirrors]]. This maze can be difficult to navigate, so choose your architecture and then choose a nearby server to use; the packages are located from the webroot of the mirror: ''pub/fedora/linux/releases/??/Everything/x86_64/os/Packages/'' (where ''??'' is a version number, and the architecture is 64bit).
-  # rpm2tgz foobar-x.x.xx.rpm
-The result is a .tgz file, so after the conversion is finished the original
+Once you've downloaded the ''.rpm'' file, use ''rpm2tgz'' to convert it:
-.rpm can be discarded and pkgtool can be used to install the .tgz file. You
-will need to ensure that the computer contains the dependency code for the
-application to function; this means that you might need to install other
-software before installing the application you really want to install. For
-instance, the Red Hat documentation tool publican offers an .rpm, but in order
-to install it there are about twenty perl modules that must be installed first.
-Warning
+<code>
+# rpm2tgz foobar-x.x.xx.rpm
+</code>
+The result is a ''.tgz'' file, so after the conversion is finished the original
+''.rpm'' can be discarded and ''pkgtool'' used to install. Ensure that the computer contains the dependency code for the application to function; this means that you might need to install other software before installing the application you really want to use. For instance, the Red Hat documentation tool ''publican'' is distributed as an ''.rpm'' and it will install, but in order for it to actually work there are over twenty ''perl'' modules that must be installed first.
+<WRAP alert>
 The user should also trust the source of the package such that they can be sure
 there is no broken, disabled, or malicious code present.
+</WRAP>
-Source Code
+===== Source Code =====
 Slackware users often prefer to compile the software they install themselves;
 that is, they take the raw text files containing the application's raw code and
-process it through the GNU gcc compiler, and then move the executable result of
+process it through the GNU ''gcc'' compiler, and then move the resulting binary (computer executable files) into their system. This has a wide variety of advantages:
-this process into their system. This has a wide variety of advantages:
-  * It allows the user to control where the executable binary (the application)
-    is installed.
-  * It allows the user to enable or disable features of the application before
-    the application is built.
+  * It allows the user to control where the executable binary (the application) is installed.
+  * It allows the user to enable or disable features of the application before the application is built.
   * It allows the user to optimize the application for a specific processor.
+  * It allows the user to review the code that goes into the building of an application, should the user wish to do so.
+  * It allows the user to change the code that goes into the building of an application, should the user wish to do so.
+  * It ensures the availability of applications to all users on any GNU, Linux, or unix-like system; source code is universal in that if an application was written for a GNU Linux system then it will compile and run on any GNU Linux system regardless of distribution.
-  * It allows the user to review the code that goes into the building of an
+The general process of compiling is in theory simple. Obtaining it is much like obtaining any downloadable software; you go to a website or a code management site (like [[http://sourceforge.net/directory/os:linux/|Sourceforge]] or [[https://github.com/notklaatu|Github]] or [[https://gitlab.com/u/notklaatu|Gitlab]]) and download the source code of an application. Typically, free software is available in both a work-in-progress ("current" or "nightly") form as well as a packaged "stable" release version. Slackermedia recommends, with few exceptions, downloading the stable version, which indicates that the code has been tested to some degree and that the programmers of the application feel confident enough in the code to package it into a ''.zip'' or ''.tar.gz'' or ''.tar.bz2'' archive, give it an official number and sometimes a release name, and offer it for download to the general non-programmer public.
-    application should the user wish to do so.
-  * It allows the user to change the code that goes into the building of an
+Once the code has been downloaded, it is uncompressed, and a series of two or three commands are issued which starts GNU gcc, which compiles the code and then sends the binaries into the system (//viz.// it is "installed").
-    application should the user wish to do so.
-  * It ensures the availability of applications to all users on any GNU, Linux,
-    or unix-like system; source code is universal in that if an application was
-    written for a GNU Linux system then it will compile and run on any GNU
-    Linux system regardless of distribution.
-The general process of compiling is in theory simple. Obtaining it is much like
+{{anchor:compile}}
-obtaining any downloadable software; you go to a website or a code management
+==== How to Compile Software from Source ====
-site (like Sourceforge or Github) and download the source code of an
-application. Typically, free software is available in both a work-in-progress
-("current" or "nightly") form as well as a packaged "stable" release version.
-Slackermedia reccommends, with few exceptions, downloading the stable version,
-which indicates that the code has been tested to some degree and that the
-programmers of the application feel confident enough in the code to package it
-into a .zip or .tar.gz or .tar.bz2 archive, give it an official number and
-sometimes a release name, and offer it for download to the general
-non-programmer public.
-Once the code has been downloaded, it is uncompressed, and a series of two or
-three commands are issued which starts GNU gcc, which compiles the code and
-then sends the binaries into the system (viz. it is "installed").
-How to Compile Software from Source
 Before you compile from source code, you should ask yourself why you are
-compiling from source code. The acceptable reasons are:
+compiling from source code. Common reasons include:
-  * You cannot find an existing Slack package or Slackbuild script for the
-    application you are about to compile. There are also no .rpm versions
-    available, or if there are, they do not install or work as required.
-  * You need new features found only in a fresh release. You have tried to
-    modify an existing Slackbuild script but it fails to compile the software
-    for you, so you want to give it a go yourself.
-    This can be difficult, because usually if an existing buildscript has been
-    broken by a new release, then the code has either changed so drastically or
-    else it (or its build system) are broken, and serious hacking will be
-    required. Still, it's free to try.
+  * You cannot find an existing Slack package or Slackbuild script for the application you are about to compile. There are also no ''.rpm'' versions available, or if there are, they do not install or work as required.
+  * You need new features found only in a fresh release. You have tried to modify an existing Slackbuild script but it fails to compile the software for you, so you want to give it a go yourself.\\
+    This can be difficult, because usually if an existing buildscript has been broken by a new release, then the code has either changed so drastically or else it (or its build system) are broken, and serious hacking will be required. Still, it's free to try.
   * You just want to build from source code.
-There is not just one way to compile software. There is the "usual" way
+There is not just one way to compile software. There is a prevalent way, but any programmer may choose a different method to manage how their software is compiled. The compilation itself is usually performed by the GNU C Compiler, ''gcc''. The way that ''gcc'' knows
-(meaning the one that you see most often), but any programmer may choose a
+what steps to take during the compile is from instructions placed in a ''Makefile'', or some configuration list; that is, a document written in a syntax specific to the compiler, which
-different method to manage how their software is compiled. The compilation
+informs the compiler what procedures and where to find supportive code to use while building the application. It may contain pointers to other code that is expected to already exists on the user's system, or to other parts of code within that application's project, and it may contain special instructions for installing the software after it has been built as well as instructions on how to un-install that application should the user decide it is no longer needed.
-itself is usually performed by the GNU C Compiler (gcc). The way that gcc knows
-what steps to take during the compile is with a Makefile, or some configuration
-list; that is, a document written in a syntax specific to the compiler, which
-informs the compiler what procedures and where to find supportive code to use
-while building the application. It may contain pointers to other code that is
-expected to already exists on the user's system, or to other parts of code
-within that application's project, and it may contain special instructions for
-installing the software after it has been built as well as instructions on how
-to uninstall that application should the user decide it is no longer needed.
-Note
+<WRAP important>
 The source code downloaded may or may not include all of the code it actually
 requires to compile and run. If, for example, Developer Foo has developed code
-for a graphics application that requires heavily on Developer Bar's opus codec,
+for a graphics application that requires heavily on Developer Bar's ''opus'' codec, then Developer Foo is obviously not going to distribute ''libopus'' along with the
-a set of code that enables the computer to handle a particular audio format,
+Foo code, because ''libopus'' is maintained by Developer Bar. Even though ''opus'' is open source and may be able to be distributed, it arguably wouldn't make sense to bundle something that a user may already have installed.
-then Developer Foo is obviously not going to distribute libopus along with the
-application's code, because libopus is maintained by Developer Bar. It is up
+It is up the user, therefore, to read the ''README'' file (or similar) packaged along with Developer Foo's application and find out what other code is required to be
-the user, therefore, to read the README file (or similar) packaged along with
-Developer Foo's application and find out what other code is required to be
 present on the computer for Application Foo to work (this is called "dependency
 resolution") and what build system the project uses, and what steps must be
 followed for the code to compile as expected.
+</WRAP>
 The general steps in compiling code, abstracted away from any specific build
 system, are:
-. Prepare the build scripts for the exact configuration of your system.
+  -Prepare the build scripts for the exact configuration of your system.
+  -Start the compiler to build the code, and then link that code to libraries it needs in order to run.
+  -Copy the new files to places that your operating system expects to find them. Icons are moved to the system icon directory, documentation to the system doc location, libraries to the system library path, executables to one of the system's application directories, and launchers to the system launcher location.
-. Start the compiler to build the code, and then link that code to libraries
-    it needs in order to run.
-. Copy the new files to places that your operating system expects to find
+Things can go wrong, of course, so here are common problems that arise in even a simple build.
-    them. Icons are moved to the system icon directory, documentation to the
-    system doc location, libraries to the system library path, executables to
-    one of the system's application directories, and launchers to the system
-    launcher location.
-Things can go wrong, of course, so here are common problems that arise in even
-a simple build.
-Common Compilation Problems
+=== Common Compilation Problems ===
-configure, cmake, etc.
+**configure, cmake, etc.**
+<WRAP indent>
+By far the most common problem during the configuration step are missing libraries. If an application requires ''libfoo'' to compile (because the developer has borrowed some code from ''libfoo'', so counts on that library being on your computer), and it cannot find it, then it is the job of the configuration script to alert you.
-    By far the most common problem during the configuration step are missing
+The solution is to install the missing libraries, and then run the make command again. If there is a make clean command, run it first to clear out any progress prior to the error.
-    libraries. If an application requires libfoo to compile (because the
-    developer has borrowed some code from libfoo, so counts on that library
-    being on your computer), and it cannot find it, then it is the job of the
-    configuration script to alert you.
-    The solution is to install the missing libraries, and then run the make
+Another potential solution is to look at configuration options (usually done by adding a ''--help'' flag to the configure command) to see if the missing library is indeed absolutely necessary. Sometimes it is possible to build without a library by using a flag like ''--without-libfoo'' or similar.
-    command again. If there is a make clean command, run it first to clear out
-    any progress prior to the error.
-    Another potential solution is to look at configuration options (usually
+Of course, you would not want to do this arbitrarily; usually the correct solution is to install the missing library.
-    done by adding a --help flag to the configure command) to see if the
+</WRAP>
-    missing library is indeed absolutely necessary. Sometimes it is possible to
-    build without a library by using a flag like --without-libfoo or similar.
-    Of course, you would not want to do this arbitrarily; usually the correct
-    solution is to install the missing library.
-make, build
+**make, build**
-    A problem during the actual compiling of code can mean that either the
+<WRAP indent>
-    configuration step made an error, or that there is an error in the code
+A problem during the actual compiling of code can mean that either the configuration step made an error, or that there is an error in the code itself.
-    itself.
-    If the configuration step made an error, then the compiler is likely
+If the configuration step made an error, then the compiler is likely looking in the wrong location for libraries that it needs. This can usually be solved by either manually correcting configuration files, or by overriding configuration files with environment variables. Unless the compiler error tells you what to look for, or you can debug the code yourself, your best chance of fixing such a problem would be to do an Internet search on the error.
-    looking in the wrong location for libraries that it needs. This can usually
-    be solved by either manually correcting configuration files, or by
-    overriding configuration files with environment variables. Unless the
-    compiler error tells you what to look for, or you can debug the code
-    yourself, your best chance of fixing such a problem would be to do an
-    internet search on the error.
-    If there is a bug in the code that is preventing it from compiling, you can
+If there is a bug in the code that is preventing it from compiling, you can either fix it (if you are a skilled programmer) or you can do an Internet search on the error to see if anyone else has encountered and fixed the problem.
-    either fix it (if you are a skilled programmer) or you can do an internet
+</WRAP>
-    search on the error to see if anyone else has encountered and fixed the
-    problem.
-make install, install
+**make install, install**
-    This step rarely fails, since all it should be doing is copying files to
+<WRAP indent>
-    your system. If it does fail, it is probably because you do not have
+This step fails less often than earlier steps, since all it should be doing is copying files to your system. If it does fail, it is probably because you do not have permission to write files to system folders. Re-try the command with root privileges.
-    permission to write files to system folders. Re-try the command with root
-    privileges.
-The problem with compiling and installing source code in this traditional way
+The problem with compiling and installing source code in this traditional way is that tracking what you have installed is nearly impossible. Any given application might install several libraries, icons, sets of documentation, and binary executables. This makes it extremely difficult to accurately and safely update components of your system when, for instance, an application requires you to update multiple libraries which in turn are being used by other applications which may be effected by the update, and so on.
-is that tracking what you have installed is nearly impossible. Any given
-application might install several libraries, icons, sets of documentation, and
-binary executables. This makes it extremely difficult to accurately and safely
-update components of your system when, for instance, an application requires
-you to update multiple libraries which in turn are being used by other
-applications which may be effected by the update, and so on.
-For this reason, Slackware has a built-in method of wrapping up a compiled
+For this reason, Slackware has a built-in method of wrapping up a compiled application as a custom-made Slack package: ''makepkg''.
-application as a custom-made Slack package: makepkg.
+</WRAP>
-Makepkg
+**Makepkg**
-To use makepkg, you do need to understand what build system the developer is
+To use ''makepkg'', you do need to understand what build system the developer is using so that you can redirect the install process (usually the final step, after the code has been compiled) to a directory of your choosing, rather than to the root of your system. Run ''makepkg'' on that directory, and you have a Slack package.
-using so that you can redirect the install process (usually the final step,
-after the code has been compiled) to a directory of your choosing, rather than
-to the root of your system. Run makepkg on that directory, and you have a Slack
-package.
 Here is an overview of common ways of defining a new installation directory:
-Makepkg Interceptors
+**Autotools**
+<WRAP indent>
+''Autotools'' is a collection of tools within the GNU build tools. Being the original freely-available build system in the world, it is by far the most common.
-Autotools
+To redirect an install, you run the usual commands, with one small addition to the install command. Therefore the first two steps are the same as always:
-    Autotools is a collection of tools within the GNU build tools. Being the
+<code>
-    original freely-available build system in the world, it is by far the most
+$ ./configure
-    common.
+$ make
+</code>
-    To redirect an install, you run the usual commands, with one small addition
+The final step intercepts the default install path and forces ''make'' to treat a ''DESTDIR'' of your choosing as if it were the root of your filesystem:
-    to the install command. Therefore the first two steps are the same as
-    always:
-                $ ./configure
+<code>
-                $ make
+$ mkdir /tmp/pkg-foo; make install DESTDIR=/tmp/pkg-foo
+</code>
+Move into the DESTDIR and use makepkg to create your Slack package:
+<code>
+$ cd /tmp/pkg-foo
+$ su -c 'makepkg -l y -c n /tmp/foo-version-$(uname -m)_SMi.txz'
+</code>
-    The final step intercepts the default install path and forces automake to
+Install the package with ''installpkg''. A Slackware package can also be used on other Slackware machines, so you may wish to store it somewhere for later use or re-distribution.
-    treat a DESTDIR of your choosing as if it were the root of your filesystem:
+</WRAP>
-                $ mkdir /tmp/pkg-foo
+**Cmake**
-                ; make install DESTDIR=/tmp/pkg-foo
+<WRAP indent>
+''Cmake'' is a build system that features a rich interactive GUI and a highly customisable build environment. In practise, the difference between ''Cmake'' and ''Automake'' is in the configuration step, so in practise using ''makepkg'' with it is the essentially the same as with ''Autotools''.
-    Move into the DESTDIR and use makepkg to create your Slack package:
+The first two steps are the usual cmake commands:
-                $ cd
+<code>
-                /tmp/pkg-foo
+$ mkdir build ; cd build; cmake ..
-                $ makepkg -l y -c n
+$ make
-                /tmp//foo-version-$(uname -m)_SMi.tgz
+</code>
+The final step intercepts the default install path and forces ''make'' to treat a ''DESTDIR'' of your choosing as if it were the root of your filesystem:
-    You can store this Slack package somewhere for later use or for
+<code>
-    re-distribution, and of course you can install it with installpkg.
+$ mkdir /tmp/pkg-foo; make install DESTDIR=/tmp/pkg-foo
+</code>
-Cmake
+Move into the DESTDIR and use makepkg to create your Slack package:
-    Cmake is a build system that features a rich interactive GUI and a highly
+<code>
-    customisable build environment. In practise, the difference between Cmake
+$ cd /tmp/pkg-foo
-    and Automake is in the configuration step, so in practise using makepkg
+$ su -c 'makepkg -l y -c n /tmp/foo-version-$(uname -m)_SMi.txz'
-    with it is the essentially the same as with Autotools.
+</code>
-    The first two steps are the usual cmake commands:
+Install it with ''installpkg''. A Slackware package can also be used on other Slackware machines, so you may wish to store it somewhere for later use or re-distribution.
+</WRAP>
-                $ mkdir build ; cd build
+**Python Distutils**
-              ; cmake ..
-                $ make
+<WRAP indent>
+''Distutils'' is the default method for installing Python applications, since it is the distribution tool that ships with Python itself. Generally, it places all configuration and installation actions in a setup.py file. It is, however, highly customisable, so be sure to read any documentation about installation that the developer of the code provides.
-    The final step intercepts the default install path and forces automake to
+To re-direct the destination of the installable files, use the ''--root'' flag when launching the setup script.
-    treat a DESTDIR of your choosing as if it were the root of your filesystem:
-                $ mkdir /tmp/pkg-foo
+<code>
-                ; make install DESTDIR=/tmp/pkg-foo
+$ python setup.py install --root=/tmp/pkg-foo
+</code>
+Move into the ''DESTDIR'' and use ''makepkg'' to create your Slack package:
-    Move into the DESTDIR and use makepkg to create your Slack package:
+<code>
+$ cd /tmp/pkg-foo
+$ makepkg -l y -c n /tmp/foo-version-$(uname -m)_SMi.tgz
+</code>
-                $ cd
+Install it with ''installpkg'', and of course you can store this Slack package somewhere for later use or for re-distribution, if needed.
-                /tmp/pkg-foo
+</WRAP>
-                $ makepkg -l y -c n
-                /tmp//foo-version-$(uname -m)_SMi.tgz
+There are many more build systems out there, and there is even the remote possibility that entirely custom install commands or no install commands could turn up. In the event of non-standard build systems, you can read the documentation included with the code and attempt a build nevertheless. If you can't figure out how to redirect the install process, you can choose to install without creating a Slack package; theoretically, that will be harder to un-install or update, but it might be a trade-off worth making, depending on the application and how badly you want it.
-    You can store this Slack package somewhere for later use or for
+As a last resort, you can contact Slackermedia for assistance; we may be able to build a package for you. Generally, this can be done for free, since it's very likely that if you are attempting to build and use a multimedia application, then other Slackermedia users may also be interested in trying it. If it is critical that a package gets created promptly, or if the package proves difficult to build even for us, then we might have to provide you with a price quote in order to get the job done to your specifications or else politely admit defeat.
-    re-distribution, and of course you can install it with installpkg.
-Python Distutils
-    Distutils is the default method for installing Python applications, since
-    it is the distribution tool that ships with Python itself. Generally, it
-    places all configuration and installation actions in a setup.py file. It
-    is, however, highly customisable, so be sure to read any docutmentation
-    about installation that the developer of the code provides.
-    To re-direct the destination of the installable files, use the --root flag
-    when launching the setup script.
-                $ python setup.py install
-                --root=/tmp/pkg-foo
-    Move into the DESTDIR and use makepkg to create your Slack package:
-                $ cd
-                /tmp/pkg-foo
-                $ makepkg -l y -c n
-                /tmp//foo-version-$(uname -m)_SMi.tgz
-    You can store this Slack package somewhere for later use or for
-    re-distribution, and of course you can install it with installpkg.
-There are many more build systems out there, and there is even the remote
-possibility that entirely custom install commands or no install commands could
-turn up. In the event of non-standard build systems, you have several options.
-You can read the documentation included with the code and attempt a build. If
-you can't figure out how to redirect the install process, you can choose to
-install without creating a Slack package; theoretically, that will be harder to
-uninstall or update, but it might be a trade-off worth making, depending on the
-application and how badly you want it. Finally, you can contact Slackermedia
-for assistance; we may be able to build a package for you (generally, this can
-be done for free, although if it is critical that a package is created
-promptly, or if the package proves difficult to build even for us, then we
-might have to provide you with a price quote in order to get the job done to
-your specifications).
 The good news is that many applications already have scripts that configure,
-compile, and create a Slack package for you. These are called Slackbuilds
+compile, and create a Slack package for you. These are called **Slackbuilds**
-(because they are simply scripts that you run in order to automate the steps of
+(because they are simple scripts that you run in order to automate the steps of
-compiling). The SlackBuild system allows you to get the best of both of worlds:
+compiling).
-the ability to compile from raw source code and transparently take the
-intermediate step of creating a Slackware Package that will be logged in /var/
-log/packages along with everything else installed on your system, but without
-doing any of the leg work. Slackbuild scripts are published in many places, but
-the largest repository of them is slackbuilds.org.
-SlackBuilds
+The SlackBuild system allows you to get the best of both of worlds: the ability to compile from raw source code and transparently take the intermediate step of creating a Slackware Package that will be logged in ''/var/log/packages'' along with everything else installed on your system, but without doing any of the leg work. Slackbuild scripts are published in many places, but the largest repository of them is [[http://slackbuilds.org]].
-One of the hallmarks of Slackware is its SlackBuild system, a powerful yet
+Read how to use [[slackbuilds|SlackBuilds]] in the next section.
-easy-to-understand and easy-to-learn method of scripting how an application is
-built. The SlackBuild system enables the user to script exactly how
-applications are compiled so that the same SlackBuild can be used on a variety
-of computers (useful in a production studio) or from computer to computer after
-a major system upgrade has been performed. SlackBuilds result in .tgz files as
-well, so managing the applications after they have been compiled is as easy as
-using pkgtool.
-This essentially combines the best of both worlds: it allows the user to
-compile from source code and to enable all the options required for the
-application to work best for the user, but also feels like a pre-built package
-since it requires very little interaction from the user in order to be
-installed.
-Note
-There is a unixy beauty to this system in that there is really nothing
-distribution-specific to it, and nothing redundant about it. It consists simply
-of a shell script which can be easily hosted on minimal storage, quickly
-downloaded, and used by anyone. Consider for a moment .deb or .rpm files, which
-in their most popular and common forms literally contain compiled code of the
-software it intends to install. This means that the source code itself is
-hosted on the appliction's homepage, it is possibly then modified by the .deb
-or .rpm maintainer, so that the application is now stored in at least two
-separate locations (its source homepage and the repository containing its .deb
-or .rpm), it can be a hefty download, compiled without any involvement from the
-user, and installed without any involvment from the user. Such complexity is
-un-unix-like, but fortunately Slackware doesn't use this method, using instead
-build scripts that are clean and efficient.
-This system was so powerful that, for Slackware 11.0, a group of Slackware
-users decided to establish a community around it, which can be found at
-SlackBuilds.org. An advantage to slackbuilds.org is that hundreds of
-applications have had scripts built for them, which are all fully editable by
-the individual user so that the compiling options are exactly the way the user
-wants them. Each user can then either maintain their private repository of
-customized SlackBuilds or simply continue to use the Slackbuilds.org versions.
-All of the scripts are reviewed and tested by the Slackbuilds.org
-administrators but can also be reviewed in advance by the user for security and
-functionality.
-To use a Slackbuild:
-. Open a web browser
-. Search for, or navigate to, the tarball of the SlackBuild files and
-    download it.
-. On your local machine, navigate to the downloaded file and untar it.
-          tar -xzvf foo-sbo.tar.gz
-. Read the README and .info files to confirm that you have all the
-    dependencies installed. If you do not, repeat these steps for each
-    dependency, and install each in the order they are required.
-. Download the source code. A Slackbuild script is just that: a script. It
-    does not contain the source code for the application. The source code must
-    be downloaded from the source code's website.
-    If there is a stable version of the source code that is more recent than
-    what the Slackbuild was written for, you may change the $VERSION setting in
-    the Slackbuild script to match the new version number.
-. Move the source code tarball into the SlackBuild directory
-          mv foo-src.tar.gz foo-sbo/
-. Change directory into the SlackBuild directory.
-. Make the SlackBuild script to be executable.
-          chmod +x foo.SlackBuild
-. Run the SlackBuild, as root.
-          su -c './foo.SlackBuild'
-. Install the resulting package.
-          su -c 'installpkg /tmp/foo_sbo.tgz'
-Introduction to sbopkg
-Prior to the release of Slackware 12.1, a frontend to Slackbuilds.org called
-sbopkg was released. Sbopkg is a command-line and dialog-based tool to mirror
-the SlackBuilds.org repository and to operate on the local copy or to operate
-on a user's own repository of SlackBuild scripts. Sbopkg allows the user to
-browse the local copy, read associated ChangeLogs, view pertinent README files,
-read and modify the SlackBuild script itself, the .info file, and the
-slack-desc files. Sbopkg also allows the user to select packages to build and
-it will download the source code for the user, check the md5sum, and build a
-Slackware package. It will also optionally install the package onto the system.
-Sbopkg does not check or resolve dependencies. It does not automatically
-install packages. It does not track what has been installed. In other words,
-this is in no way apt-get or rpm for Slackware; it is a local front-end for
-Slackbuilds.org and does not duplicate or overlap the function of pkgtool or
-the responsibilities of the user as the primary manager of the system.
-To obtain sbopkg, visit sbopkg.org and download the Slackware package. Then,
-open a terminal and use either pkgtool or installpkg:
-$ su -c 'installpkg sbopkg-VERSION-noarch_1-cng.tgz'
-Among the files installed along with sbopkg, there is /etc/sbopkg/sbopkg.conf,
-which contains all pertinent configuration options for sbopkg. It is safe to
-use the default settings. To start sbopkg, launch it as root by typing su -lc
-sbopkg (The -l is to obtain the root environment some packages require).
-Upon first launch, sbopkg creates, as defined in the sbopkg.conf file, a local
-copy of the scripts available from slackbuilds.org in /var/lib/sbopkg/SBo/x
-(where x is the latest stable release of Slackware), a log in /var/log/sbopkg,
-a queue directory in /var/sbopkg/queues, a cache in /var/cache/sbopkg, and a
-local tmp directory called /tmp/sbopkg.
-After sbopkg has launched, the user is delivered to an ncurses interface; use
-the Up and Down arrow keys to navigate through the main menu, Return to make a
-selection, and the Right and Left arrow keys to select which button on the
-bottom of the menu (OK, Cancel, Back, etc) the Return key activates.
-The first step with sbopkg is to sync with the remote server; this is the top
-selection in the sbopkg main menu. This copies all available scripts from
-SlackBuilds.org and saves them into directories corresponding with the
-categories defined by SlackBuilds.org (academic, accessibility, audio, etc).
-This allows the user to browse the mirrored repository in sbopkg whether or not
-the user is online, and also modify the scripts before using them to install
-software.
-After the initial rsync, the user can view the SlackBuilds.org ChangeLog, which
-documents the most recent updates applied to the SlackBuild repository, whether
-these are bug fixes in the scripts or updated packages. A user may also
-subscribe to the SlackBuild user mailing list at http://lists.slackbuilds.org/
-mailman/listinfo/slackbuilds-users.
-A list of all SlackBuild packages installed on the user's system may be viewed
-via the Packages menu selection, which looks at /var/log/sbopkg and displays
-the packages installed whose tags match the currently active repo's tags (by
-default, _SBo). Similarly, selecting the Update menu item will compare
-installed packages to those available in the local mirror and identify any
-packages that have updates available.
-Finding a package to install is done with the Browse menu selection, or the
-Search selection. Browse takes the user to a list of top-level categories as
-defined by SlackBuilds.org; use the Return key to select a category and browse
-through the packages. Hitting Return again will display the details about a
-package, such as the README file, the SlackBuild script itself, and more. To go
-back in the list of packages or to the list of categories, use the Right arrow
-to select the Back button on the bottom row of sbopkg's interface, and press
-Return or type Alt+B. The convention of using the Up and Down arrow keys (or
-accelerators) for the top menu of sbopkg and the Right and Left arrows (or Alt+
-accelerator) for the bottom row is used throughout sbopkg, except in textbox
-dialogs where the arrows scroll the text.
-The search function in sbopkg works as would be expected: hit Return on Search
-to be taken to a pop-up search field, type in the term you are searching for
-(it is case-insensitive) and hit Return again. Sbopkg returns all packages
-matching the search term; i.e., if a search is performed for the term "ink"
-then sbopkg will return "link-grammar", "inkscape", "libnfnetlink", "elinks",
-"wink", etc. Common bash wildcard characters are also supported, such that a
-search for "?ink*" returns the same list minus "inkscape" which has no
-character prior to "ink".
-Building and Installing Software with Sbopkg
-Sbopkg can build and install software. These are two separate processes. If you
-elect to only build software, the resulting Slackware package (.tgz file) is
-left in /tmp by default. This location is controlled by the OUTPUT variable in
-the config file. It can then be installed via pkgtool or installpkg, or taken
-to other machines of the same architecture and installed on those, or simply
-stored for later use. Alternatively, sbopkg can be set to install the software
-after it has been compiled.
-Building and/or installing can be done from different places; the Build item is
-the final menu item on each individual package menu of unbuilt packages, and it
-is invoked with the Process Queue item in the Queue sub-menus. Sbopkg will
-prompt the user to perform only a build of the software or a build-and-install.
-Slackermedia recommends build-and-install for single or small groups of users
-in which compile time is not an issue; for building larger install bases, it
-may be more efficient to build once and install the resulting binary rather
-than having each computer compile it individually.
-To build or install a package via sbopkg, the first step should always be to
-view the README file. This displays a brief description of the application
-about to be installed, any options that may be passed to the SlackBuild, and
-any applications upon which the application depends (required dependencies can
-always be found on SlackBuilds.org). Sbopkg does not automatically resolve
-dependencies so it is up to the user to ensure that all listed dependencies are
-installed on the system before proceeding. READMEs can be viewed from various
-places, including selecting Queue ? Process ? View READMEs when using the
-dialog interface or using the -R flag from the command line.
-Assuming, for the purpose of this example, that there are no dependencies, the
-next step might be to view the .info file, which is a SlackBuilds.org-specific
-file of metadata which lists the canonical program name, the version for which
-the SlackBuild script was written, the project's homepage, the exact link where
-the source code for the program can be downloaded, the md5sum of that
-downloadable package, the SlackBuild script's maintainer's name and email, and
-the SlackBuilds.org administrator who approved the script.
-Next, the SlackBuild script itself can be reviewed. Although all SlackBuild
-scripts have been reviewed and tested by SlackBuild maintainers, it is a good
-idea to review the script, both for security purposes as well as to ensure that
-the application is going to be installed the way the user thinks it's going to
-be installed. There are some scripts that feature options that the user can
-take advantage of (like turning off or on codec or plugin support), while other
-scripts simply help elucidate optional components that the application will use
-if available but that are not dependencies themselves. Other applications
-feature an unusual build process such that a SlackBuild script may be more
-convenient for most users but a disadvantage to a user who relies on that
-program and would be better off installing directly from the project's code
-repository.
-If additional options are available in the SlackBuild script, the user's local
-copy of the script and/or .info file can be edited from within sbopkg by
-selecting the Custom menu item. This will open the SlackBuild script in the
-user's text editor of choice (defined by the EDITOR environmental variable).
-For example, if the SlackBuild script for LiVES was written for version 1.1.8
-but a new version of LiVES has been released and a user wishes to install the
-newer version, all that is required of the user is that the version number be
-changed from 1.1.8 to, for instance, 1.2.0 (making the corresponding changes to
-the .info file's VERSION and DOWNLOAD fields). The script can be saved and run
-in sbopkg and the correct version of LiVES would be downloaded, compiled, and
-optionally installed.
-Any change can be made to a SlackBuild script in this way, whether the user
-wishes to hard code a unique feature into the script, or define a variable that
-is described in the README file, update the version number, modify build paths,
-and so on. If the only thing that is desired is to set a build option, however,
-this can be done by selecting the Options item and typing OPTION=value ? in the
-entry field. While editing the SlackBuild is a persistent change, the edited
-version would have to be kept in sync with version changes which happen often.
-Using custom options also persists but only needs to be kept in sync with
-option changes which happen rarely. Changing a SlackBuild script, of course,
-requires at least some very basic knowledge of bash scripting and the
-installation process. It may be that a software package has changed
-substantially from one version to the next and so a simple update of the
-version number may not be all that is required, so if a user is opening a
-SlackBuild script for modification then the user should truly understand what
-is being done in the script, or be prepared for the build to potentially fail.
-The Sbopkg Queue
-One of the most powerful features of sbopkg is its queue, which makes it
-possible for a user to create a list of packages to have installed in a
-particular order and use the list on other computers. Slackermedia makes
-extensive use of queue files to co-ordinate which packages should be installed
-as a basis for a good multimedia system. From the main sbopkg menu, select
-Queue and press Return. The Queue menu contains items to view the current
-queue, to modify the queue, load an existing queue, save a queue, rename or
-delete existing queues, add all installed packages to the queue (for creating
-package templates to enable restoration of the current package list or to
-transfer to another machine), and to process the current queue.
-A queue is created from the sbopkg GUI by finding a package via either Browse
-or Search and selecting Add to Queue. This adds the package to a temporary
-session-only queue file.
-A typical use for this would be, for instance, when installing Inkscape. Doing
-a search for Inkscape reveals that there is a SlackBuild available, but that it
-depends on a number of other packages such as pangomm, cairomm, and others.
-Adding Inkscape to the queue allows the user to then go seek out SlackBuild
-packages for Inkscape's dependencies and either install them one by one, or add
-them to the queue as well. If they are added to the queue, then obviously the
-queue will attempt to install Inkscape before it installs the dependencies, so
-there are special functions in the Sort Queue submenu of sbopkg's Queue menu to
-either manually rearrange the order of the queue, or simply reverse the queue
-such that it is processed in reverse order. A simple reversal of the queue
-sometimes does work, but it may be insufficient since a dependency of one
-application may have its own dependencies which may require manual re-ordering
-to do subsorts in the queue. Alternatively, queuefiles can be created and
-edited with a text editor.
-The Queue menu is accessed from the main sbopkg menu by selecting Queue and
-contains items to view the current queue, which is dynamically created by the
-user during an sbopkg session and will be erased (unless saved) when sbopkg is
-stopped. The Sort item allows the user to reorder the list of applications in
-the queue while Remove allows the user to delete items from the queue. Save
-allows a queue file to be saved to the harddrive for later use; this is useful
-when doing multiple installs of Slackware on a number of machines; a queue file
-can be used on each machine so that the same packages are installed with
-minimal effort. By default, queue files are saved in /var/lib/sbopkg/queues.
-To load a pre-existent queue file into sbopkg, select Queue ? Load and check
-the desired queuefile(s) in the list. To run a queue file, select Process Queue
-from the Queue menu.
-For example, if you have downloaded the av queue file from Slackermedia, then
-to load it into sbopkg, simply invoke sbopkg as QUEUEDIR=/path/to/dir/
-containing/queuefile sbopkg and it will appear in the checklist and can be
-checked as usual. The queue file would then be loaded into sbopkg and you can
-view it, modify it, remove or reorder applications, and finally process it.
-Advanced Uses of sbopkg
-Sbopkg can also be used directly from the command line. Its options can be
-listed with sbopkg -h and details can be found via its manual page (man sbopkg
-), but the most direct and simple command is (to use the earlier example) su
--lc 'sbopkg -i av' which will search for an application or queue file called
-"av" and install it (if an application) or the programs in it (if a queuefile).
-If both a program and queuefile exist with the same name, you'll be prompted to
-specify which. If a queuefile is intended, specifying the .sqf extension will
-avoid the prompt. If you know the name of an application and feel confident
-that you you have met all its dependencies (or can meet them all within the
-same command), this is probably both easier and simpler than loading sbopkg's
-graphical environment.
-Other command line options include causing sbopkg to rsync to slackbuilds.org,
-building without installing, diverse search options, viewing changelogs, and so
-on.
-It is also possible to maintain a local repository of customized SlackBuilds
-rather than, or in addition to, synchronizing with SlackBuilds.org. The local
-repository is stored in /var/lib/sbopkg/local by default and can be made active
-by either selecting it from Utilities ? Repository or by invoking sbopkg as
-sbopkg -V local. Additionally, the location of the sbopkg repository can be
-defined in the /etc/sbopkg/sbopkg.conf file. If necessary, you may also pass
-the -d flag to specify an alternate directory for SlackBuilds repositories or
-by maintaining two configuration files, since sbopkg can be passed an alternate
-configuration file (sbopkg -f FILE) on the command line.
-sport
-Sport, the "Slackware Port" system, is a simple shell frontend to
-Slackbuilds.org. It is meant to be simpler and less interactive than sbopkg,
-and instead emulate the BSD port system, or Gentoo's emerge.
-Like other Slackware package installation applications, sport is not a package
-manager. However, it does help you search through your collection of
-SlackBuilds, read relevant files about each SlackBuild, and then execute the
-build and install processes.
-Note
-Since the most prolific and uniform collection of SlackBuilds is
-SlackBuilds.org, and since Slackermedia is so heavily reliant upon
-SlackBuilds.org, sport was largely modeled after the structure of SB.o,
-although it is not restricted to it and technically will work with any
-collection of builds (such as your own personal collection of modified builds,
-or those of trusted associates).
-To install sport, download its source code and use sport to install sport (yes,
-you can use sport to install itself):
-  $ git clone gitorious.org/slackport/sport.git sport.git
-  $ cd sport.git
-  $ su -c
-  './sport install .'
-To use sport, you must have a local repository of SlackBuilds. Since
-Slackermedia relies heavily upon slackbuilds.org, it is worth while to pull the
-entire listing of SlackBuild scripts from the site:
-  $ su -c 'mkdir -p /usr/ports'
-  $ su -c 'rsync -av rsync://slackbuilds.org/slackbuilds/$(awk '{print $2}' /etc/slackware-version)/ /usr/ports/'
-If you want to use sport and sbopkg on the same system, you should use the same
-location that sbopkg uses (or else use the sport location for sbopkg). An
-example of the former:
-  $ su -c 'mkdir -p /var/lib/sbopkg/SBo/$(awk '{print $2}'
-  $ su -c 'rsync -av rsync://slackbuilds.org/slackbuilds/$(awk '{print $2}' /etc/slackware-version) /var/lib/sbopkg/SBo/xx.x/'
-Before you can use sport, you must set the location of your local SlackBuild
-repository. Open /etc/sport.conf and edit the SBOPATH and MASTER variables. For
-example, assuming xx.x is your version of Slackware:
-    SBOPATH=/usr/ports
-    MASTER="rsync:?/slackbuilds.org/slackbuilds/xx.x"
-There are a few different ways to use sport, but it was written with BSD Ports
-in mind, so its intended workflow mimics the way that the BSD Handbook guides
-users through the intended usage of their Ports system.
-In general, the workflow would be:
-. Search for a term or package name that you want to install
-. Read about the package you find in order to learn about what libraries and
-    other applications it depends on, as well as any important build notes
-. Download, build, install
-These tasks are each individual commands within the sport toolset. For each
-flag, you can use every common convention for switches. For example, these
-would all do the same thing:
-  * sport --search foo
-  * sport search foo
-  * sport s foo
-  * sport -s foo
-Sport Walkthrough
-The first step in the workflow is to find what you want to install. If you only
-have an idea of what you want, then you'll want to search for matches to some
-keyword:
-    # sport search foo
-    network/emacs-foo.tar.gz ... emacs-foo
-    (simple Emacs interface of foo)
-    network/foo.tar.gz ... foo (text based web
-    browser and pager)
-The search function of sport performs a fuzzy search on any term you provide. A
-search for "foo" therefore returns the category and packages names for both the
-stand-alone foo and the Emacs foo mode.
-Note
-If you only want to browse through your SlackBuilds tree without having to
-think up search terms, cd into /usr/ports (or whatever you have set SBOPATH to)
-and browse its contents.
-If you find something of interest but want to see if you already have it
-installed, use sport check:
-  # sport check foo
-If nothing is returned, then you do not have that application installed.
-The next step in the typical workflow is to read about the package you are
-about to install, so that you know about any important build configuration
-options, or dependencies that you should install first. Use sport cat to see
-all relevant notes in a SlackBuild. If the package search returned only one
-match, then you can use just the packagename, but if there were multiple
-matches then you should provide both the category and package name:
-  $ sport c net*/foo
-If you have changed directories into your SlackBuild tree and are in the same
-directory as the SlackBuild file, you can cheat and provide the path to the
-package with a dot-slash:
-  $ sport cat ./foo
-Or if you are in the SlackBuild's directory, just use a dot.
-  $ sport cat .
-This displays the README and the .info files of the package, so that you can
-see what the application claims to do, and what dependencies are recommended
-and required.
-If the package you want to install has dependencies, you should resolve those
-dependencies before continuing. Unlike the BSD Ports and Gentoo emerge systems,
-sport does not resolve dependencies for you. That way, if you have already have
-a package or a SlackBuild for a dependency (or you prefer to compile it
-yourself), you can use it instead of whatever an automated "package manager"
-happens to find lying around.
-Note
-"Resolving dependencies" may sound mysterious but all it means is that you will
-have to install some additional system libraries or smaller applications before
-you install the application you are trying to obtain. To resolve the
-dependencies of foo, you would take note of the libraries it requires (bar and
-baz) and then use sport to install each one before then installing foo itself.
-Once you have resolved all dependencies, you are ready to build the package.
-There are two commands you can use; sport install will build the package and
-install it onto your system (leaving a copy of the finished Slack package in
-the default build location for SBo packages: /tmp), while sport install
---build-only only builds but does not install the package.
-  # sport install foo
-Again, if you are in the directory containing the SlackBuild you want to
-install, you can cheat and provide the path to the package with a dot, meaning
-that the build script is in the current directory:
-  # sport -i .
-If you are fastidious about disk space or keeping a tidy SlackBuilds tree, use
-sport clean foo to remove the directory containing the source code and
-SlackBuild. It of course leaves any compressed copy of your SlackBuild
-directory (the SlackBuild.org structure).
-Warning
-If you are not using the SlackBuild.org tree, then you should either keep your
-originals as compressed .tar.gz archives or you should either modify or not use
-the clean command.
-As you can see, sport may be used from anywhere in your filesystem, or you can
-use it as you "crawl" through your SlackBuild tree. It's a handy and flexible
-tool that can help make the potentially repetitious process of downloading,
-compiling, and installing software easier.
-Advanced Sport Usage
-Since sport is just a BASH script, you can use the usual BASH conventions to
-add flexibility to your commands.
-To pass build options through sport, provide the option (usually defined in the
-README of the SlackBuild).
-  # WIDGETS=yes sport install foo
-To pass make flags through sport, use MAKEOPTS.
-  # MAKEOPTS='-j8' sport install foo
-If you need to do some special kind of install (such as an upgradepkg rather
-than an installpkg) then preface your sport -i command with the INSTALLER
-environment variable:
-  # INSTALLER=upgradepkg sport i .
-Or something more complex:
-  # INSTALLER="upgradepkg --install-new" sport -i multi*/foo
-And so on.
-Queue Files
-Sport supports batch, or queue, files.
-For your initial Slackermedia install actions, you will use a Slackermedia
-queue files (slackermedia-huge.sqf, for example) but you can also create and
-maintain your own queue files. To create your own queue, just echo the package
-names into a plain text file, newline delimited, in the order you wish for them
-to be installed.
-Note
-In the event of two packages sharing the same name, use both the category and
-package name, but usually just the package name will do.
-Here is an example of a simple queue file for foo:
-baz
-bar
-foo
-Save these three lines as foo.list (or any filename) and then have sport
-process it using standard BASH re-direction:
-# sport $( < foo.list)
-For full details on using sport, view the man and info pages bundled with it.
+<WRAP centeralign>
+<wrap fa>[[linuxaudio|R]]</wrap> <wrap fa>[[start|S]]</wrap> <wrap fa>[[slackbuilds|Q]]</wrap>
+</WRAP>