Put very simply, a txz package is a compressed archive (like a zip or tar archive) that contains the files that make up a software application, library, or other "linux package". When the package is installed, these files are copied into your root filesystem ("/") and are ready for use; inside the txz package, the files reside in the same directory tree as they would inside your filesystem. For example, if you have a package called "mypackage.txz", which contained a file inside it at "mypackage.txz/usr/bin/my-package", and you installed the package, this file would be extracted from the txz package and copied into your root filesystem, at /usr/bin/my-package.
You can see examples of the files contained inside a slackware package by opening and reading any of the files inside the folder /var/log/packages.
So, inside the txz we have a number of regular files which are copied into your system, but there are also a couple of files in slackware packages which contain metadata (information about the data) and installation instructions. These are located inside the "install" directory of the txz archive, and typically consist of a file called "slack-desc" and a file called "doinst.sh". Slack-desc contains a brief description of what the software inside the package does, and this information is displayed on your screen when you install the package. The file "doinst.sh" is a little bit more interesting. This is a script full of installation instructions and it gets run whenever you install the package. The scripts vary for each package, but typically they will create necessary symlinks (shortcuts) for the package to work, update cache files, update configuration files (or leaving configuration files in place and installing a new version for you to consider), etc. The doinst.sh script is a plain-text bash script, so you can read the script to find out exactly what steps it takes during the installation process.
You can see an examples of these scripts by looking inside the folder /var/log/scripts.
During the installation of a package, a couple of other files are generated. The 'doinst.sh' file from the /install directory inside the package gets renamed to match the package name and is copied into /var/log/scripts, so you have a record of what instructions were run when the package was installed. A text file is also created, named after the package, and placed in /var/log/packages. This file is populated with a description of the package (taken from slack-desc) and a listing of all of the files that were inside of the package, which makes these files very handy. For example, if you're wondering which package contained a certain file, "/etc/mypackage/foo.bar", you could simply run: 'grep foo.bar /var/log/packages/*' and the grep utility would print a list of all packages which contained files named 'foo.bar'.
Now that you know a little more about what happens during the installation process, let's discuss the commands used to actually install the package. This is done with the aptly named 'installpkg' utility. For example, to install the package, 'myapp-1.1.txz', you would open a terminal, cd to the package's location, and type, 'installpkg myapp-1.1.txz'. This sets the process in motion; the package is extracted, all files are copied into their proper location, and the doinst.sh script is run. An important option for Porteus users is the ability to install packages to a directory other than the root directory. This allows you to copy all of the files and run the install script in a clean location, so that you can manipulate the files and convert them into a Porteus xzm module. This is done by adding '-root /path/to/fakeroot' to the command, for example 'installpkg root /tmp/mynewapp myapp-1.1.txz'. In this example, if you had a file inside the package at /etc/foo.bar, it would be placed into /tmp/mynewapp/etc/foo.bar (note that you must first create the directory /tmp/mynewapp).
Uninstalling a package is accomplished easily as well, with the 'removepkg' utility. You could open a console and type 'removepkg myapp' and the removepkg utility will search for a file in /var/log/packages/ matching 'myapp', and remove the files in that package from your system. Keep in mind that running 'removepkg' in Porteus will uninstall the package from your live filesystem and these changes will survive a reboot if (and only if) you are saving your changes, but the packages will not be removed from your modules. For this same reason, using 'installpkg' is not the recommended method for permanently installing software in Porteus. Instead, you should convert your packages into xzm modules, using the txz2xzm command. This command runs 'installpkg -root' to install the package to a fake root directory, then compresses that fake root directory into a Porteus xzm module. More on that here: http://porteus.org/info/docs/36-modules ... udies.html
Creating and modifying packages:
Txz packages can be created from a directory populated with files. This directory should be a 'fake root', containing a hierarchy of directories that mirror where the files should go when they are installed, just like the txz package itself. As another example of this, you could have a folder named /tmp/myapp, and inside this directory would be etc/myapp.conf, usr/bin/myapp, etc. If you are creating a package for use by others, you should also have an 'install' directory in this fake root, with a valid 'slack-desc' file (containing a description of the package) and a 'doinst.sh' file containing any installation instructions. With all files present, you can then cd into the fake root directory and create your package with makepkg. The syntax would be: 'makepkg -l y -c n /tmp/mynewpackage-1.0-i486.txz'. The '-l y' option tells makepkg to delete symlinks in the fake root tree and inserts lines into the doinst.sh script to recreate the links upon install. The '-c n' option tells makepkg not to reset folder permissions and ownership (specifying '-c y' would cause all folders to be set by chmod to 755 and owned as root:root). While you can create a package out of any collection of files, most packages contain compiled binary files, which are built from source code. Slackware packages are compiled from source using special scripts that automate the configuration and compilation of the source code, as well as creating the fake root package and running 'makepkg' to generate the finalized package (my next tutorial will cover the creation and use of slackbuilds).
At times it is necessary to break apart a package in order to maintain or modify it. This can be done with the 'explodepkg' command, which extracts the txz package into a directory tree without installing it, so symlinks are not created (the doinst.sh script is not run), and the slack-desc file is not copied into /var/log/packages. After modifying the exploded package contents, you can then repackage them once again using 'makepkg'. An example for this would be:
- Code: Select all
cp /mnt/sdb2/myapp.txz /tmp/fakeroot
mv usr/wrongname.txt usr/rightname.txz
rm myapp.txz #(we don't want to leave the .txz package in the fake root or it will become a file in the new package)
makepkg -l y -c n /mnt/sdb2/myapp.txz
In this example, we replaced a package that contained an error (a file with the wrong name) with a corrected package.
I hope tutorial is useful to those who are new to using Slackware-based package management; please feel free to let me know if you have questions or suggestions for additional information to include.