Linux.com

Feature

A look at Slackware's package utilities

By Mayank Sharma on February 20, 2007 (8:00:00 AM)

Share    Print    Comments   

Slackware Linux is the oldest surviving Linux distribution. Late last year the project marked 13 years of non-stop development with the release of Slackware 11.0. The distribution is best known for its no-frills, minimum customizations approach to applications like KDE. It's also notorious for its reluctance to switch to new version of several popular applications like Apache or GCC. No surprise then, that its package management system has seen little change over the years and is still available in just one flavor -- vanilla.

A Slackware package is a simple gzipped tarball of the form name-version-architecture-revision.tgz, for example, php-5.1.6-i486-2.tgz. When you uncompress and extract the contents of this tarball with tar -xvf php-5.1.6-i486-2.tgz, you get three directories, etc, usr, and install. The install directory contains a do-inst.sh script that, in essence, helps Slackware assimilate the contents of the unzipped etc and usr directory into the /etc and /usr directories under the root directory.

Installation on Slackware might sound plain and simple, but it really isn't. Sure installing stand-alone applications isn't an issue. But when it comes to installing applications that depend on other programs and libraries, the Slackware package management tools fall flat on their face.

Unlike packages made for repository based solutions, like Debian's apt-get and Fedora's yum, Slackware packages were not designed to be dependency-aware -- and hardcore Slackware users would have it no other way. Installing dependencies by hand does have an advantage. It allows an administrator to remain in control of the libraries and programs installed on the system.

But being one of the oldest distributions has its advantages. Thanks to its faithful bunch of developers, Slackware has perhaps the largest collection of package management tools. Let's look at some of them.

The venerable package tools

Slackware has a bunch of packaging tools that are as old as the distribution they support. Up front is the pkgtool utility that brings up a ncurses menu driven interface. With this tool you can install packages from the current directory or from another one. The tool is also aware of all the installed applications and can be used to remove several at one go. You can also view an application's brief description and a complete list of files contained within any installed application.

Apart from pkgtool, Slackware has tools that will help you install, remove, and upgrade packages. The installpkg, removepkg, and upgradepkg utilities all take the name of an application as an argument and install, remove, or upgrade them, respectively.

You can also use the -warn option with the installpkg and removepkg commands. Instead of installing an application, this switch will simply print a list of files and directories that would be overwritten or removed if you install a particular package.

Want to know what a package will install before you pull the trigger? Use the explodepkg command to uncompress the tarball into the current directory and view its contents.

Installing non-slackware packages

Despite Slackware's longevity, many application developers don't supply a Slackware package. In that case you have two options, either build the application from source or use its RPM package if it's available. To make use of an RPM package it has to be first converted into Slackware's package format. This can be done using the rpm2targz and rpm2tgz tools. I successfully converted RPMs of several simple applications like that of Joe Text Editor, into tgz and installed and removed them without any issues.

If you decide to install from the source, you should do so through the CheckInstall tool, which itself is available as an easily installable Slackware package. Installing an application from source involves running the ./configure, make and make install commands that configures, compiles, and installs the application.

CheckInstall kicks in just before make install and learns everything the new application will add to the system. It then simply creates the Slackware package. We've written about CheckInstall in our CLI Magic series.

Repository-based tools

The biggest drawback of Slackware's pkgtool is that it can only install packages available locally on the machine. This is where the Slackpkg tool comes into play. Slackpkg is designed for installing or upgrading packages through network. It works on the principles of online repositories, much like Debian's APT. The tool gets package information from one of the official Slackware mirrors. You can use this information to search for packages and automatically download and install them.

Slackpkg isn't installed by default, but is available in the extras/ directory on the second Slackware installation CD-ROM and can be easily installed using installpkg. Before the tool can be used, you need to edit the /etc/slackpkg/mirrors file and select one mirror by uncommenting its corresponding location.

After selecting the mirror, the slackpkg update command will download some important files from the mirrors, like the GPG key, which will help verify the authenticity of the packages. Once the tool has updated itself, it can be used to manage packages. Once a package has been retrieved from the online repository, in the background, Slackpkg uses Slackware's installpkg to install them, along with the removepkg and upgradepkg tools to remove packages and install updates.

The tool puts Slackware on par with other modern distributions that can be completely installed and updated over the network. But it still has some rough edges. As we've mentioned in our Slackware 11.0 review, the tool's search feature can sometimes return strange results.

Tools that resolve dependencies

All the tools that we've covered until now are incapable of resolving dependencies. This is a big turnoff for many desktop users. Just blaming the tools wouldn't be appropriate. Like I've said earlier Slackware's package format itself isn't designed to be dependency aware. This led several Slackware users to design a new format, called the Extended TGZ. Packages in the extended TGZ format contain information about the package's dependencies.

Third-party Slackware packages, aware of dependencies, are maintained at LinuxPackages.net and Slacky.it. These resources have active communities and between them, you'll find the latest versions of most of the applications you need.

But the packages themselves can't resolve dependencies, and neither can Slackware's pkgtool or slackpkg. This paves the way for the Swaret and Slapt-get tools.

Swaret is probably the most popular Slackware package management application. Like Slackpkg, it's designed to install, upgrade packages over the Internet and it can grab packages from the official repository. Furthermore, with swaret you can grab packages in third-party repositories like LinuxPackages.net. Swaret is also capable of installing missing libraries that an application depends upon.

After grabbing and installing swaret's TGZ, rename its sample configuration file to /etc/swaret.conf and edit to select mirrors and other options, like its local tgz store. Unlike upgrades with the upgradepkg tool, swaret can backup a package that its upgrading and can rollback to this older version. You can script swaret to automatically update your Slackware distribution when a new version is released.

But if you want true dependency resolution, there's no better tool than slapt-get. It works with multiple repositories and can resolve both libraries and application dependencies. I prefer slapt-get to swaret, since it has all of swaret's features, and its options are very similar to apt-get, and is scriptable too. Like slackpkg, slapt-get uses Slackware's native package management tools, installpkg, removepkg, and upgradepkg for managing packages. Slapt-get also has lots of usage-related documentation.

Portage for Slackware

The Gentoo Linux distribution is best known for its Portage package management system. Portage is a collection of build scripts that is used by Gentoo's emerge utility to configure, compile and install a package. The system also provides for dependency resolution. If you'd like to have a system like Portage on Slackware, there are two options: Emerde and Portpkg.

Emerde syncs with Gentoo's Portage tree, downloads the necessary build scripts, and installs them on Slackware. Emerde is still in beta and its developers advise installing it on a minimalistic Slackware installation to avoid possible conflicts with packages. The application can also be used to install Slackware packages directly.

Another approach to bring portage-like functionality to Slackware is Portpkg. Instead of using Gentoo's portage, Portpkg uses Slackware's own build file, SlackBuild. Portpkg has been built from the ground up to custom fit Slackware and can be used along-side swaret and slapt-get to keep the system updated, without causing any package conflicts.

Between the two systems, Portpkg is the more comfortable one for new users since its similar in usage to Slackware's installpkg tool. Since Emerde syncs with the online repositories, it's not a viable option for users with slow Internet connections. On the other hand, don't expect Portpkg to have build files for every application out there.

Conclusion

Slackware is designed for users who prefer to be in complete control of their system. They swear by Slackware's package management system and will have it no other way. However, another other group of users, spoiled by the one-click installation systems of newer distributions, fail to understand Slackware's lack of dependency resolution.

Patrick Volkerding, founder, maintainer, and developer of Slackware must be credited for making provisions for automatic dependency resolution for those who choose to do so. And applications like swaret and slapt-get take full benefit of this. On the other hand, by adopting source-based installation methods from other distributions, upcoming tools like Emerde and Portpkg might just satisfy both old and new users.

Share    Print    Comments   

Comments

on A look at Slackware's package utilities

Note: Comments are owned by the poster. We are not responsible for their content.

Slackware packaging

Posted by: Anonymous Coward on February 21, 2007 08:34 AM
I think that the real beauty of Slackware is its package management. I wish I had a dime for every time a package management system wanted to uninstall the entire DE simply because I asked it to remove one library. Slackware puts the user in complete control over the system so that he/she can mold it into anything they would like. That is what I came to linux for. Maximum control. I want to have more intimate knowledge of what is going on with my machine. I think all Slackers do.

#

Enhanced pkgtools

Posted by: Anonymous Coward on February 21, 2007 11:44 AM
There's enhanced and compatible pgktools available for Slackware. Tukaani pkgtools got lot of improvements. You should check them out if you want more speed and features. <a href="http://tukaani.org/pkgtools/" title="tukaani.org">http://tukaani.org/pkgtools/</a tukaani.org>

#

Did he say 'enhanced package?'

Posted by: Anonymous Coward on February 21, 2007 01:44 PM
Ummmm. Uhhhhhhh.

#

slackware package management

Posted by: Anonymous Coward on February 21, 2007 05:18 PM
A time ago.. (far far away) there was RPM or apt or tgz. Of all of these only tgz was unhindered by complaints about dependencies.
I have tried many different distrobutions and on most all of them I have to download a bunch more whatevers than came on the CD. Except for Slack.... Why is this?
Since '94 when I discovered the slackware disksets I have been amazed at the simplicity of the installation. Bang! there I was.
A Slackware TGZ is pretty much a snapshot of the system that it was compiled against. So I can be confident that it will not need to go rambling about and complaining that it needs some obscure library. (Hey baybee!! Slack allready has all the libs you need).
Granted, some people cannot appreciate the simplicity that this format provides. To those I will simply say: Install Slack, then install a debian and then a rh based system. Which ones need to download and install updates?

#

best garbage management tools

Posted by: Anonymous Coward on February 21, 2007 05:30 PM
> Installing dependencies by hand does have an advantage.
Oh, really? Then starting up a car's engine by hand, with that special handle, does have an advantage too, especially in face of automatic transmission.

It's just that nobody had even seen that for years...

> It allows an administrator to remain in control
> of the libraries and programs installed on the system.
No it doesn't. It's a strawman argument which is constantly heard from those who don't understand that dependencies aren't pulled down from thin air, to some extent these are present in ELF itself.

If you want to break deps on e.g. RPM system, go ahead and turn it into slackware by using --nodeps option -- you're the administrator, even if lame one, you've got the power to shoot yourself in a foot. If there's an erroneous dependency and you don't want to shoot, you can hack up a fake dependency provider package in a minute.

Still, lots of broken, superfluous, or mystic dependencies are alarming -- one of major issues in RH-like distros to me (these usually have monster packages like full perl which just pull *everything* in if dependencies are proper, and might still have missing ones).

So before praising slackware for being dumb enough to let you shoot yourself in a foot without any problem now (just to find out something not starting or misfunctioning maybe considerably later and mess with ldd), *please* do mention the distro you moved from. I bet an Ukrainian beer bottle against broken NE2000 that it was Red Hat Linux in 80% of cases, its straightforward (and as broken) derivatives in 10%, and the rest is reserved for cases when even proper distro (dependency-wise, like e.g. Debian -- there are proper RPM-based ones too) just wasn't grokked by a person preferring latent time loss with ldd to doing even small homework.

Still, Slackware users are of course free to use their favourite distro, but *please* don't fool newbies with that quasi technical praise: I have yet to see any slackwarist who after some consideration wouldn't admit he's just *emotionally* attracted to good ol' things he's used to.

And I have to personally thank the article's author for inspiration: "Slackware has best garbage management tools".

Folks, a manager who can't influence the way things are done isn't a manager. A package manager which can't account for dependencies is mismanager.

Like it or not, just try to support more than one system (or a few cloned ones) to understand how childish you were.

--
Michael Shigorin

#

I agree (in a way)

Posted by: Anonymous Coward on February 22, 2007 06:04 PM
What people often mis-understand is that it's not that the Slackware package management tools are great, they are not - anyone other is better.

It's the quality of the packages that Pat creates is what's great about Slackware.

I'm often amazed when I see really f**ked up software on the other distributions. They really destroy my view of Linux like I know it.

--
Damjan, a longtime Slackware user, but now also playing with ArchLinux on non-work related computers<nobr> <wbr></nobr>:)

#

I disagree, in various ways

Posted by: Anonymous Coward on February 23, 2007 01:02 AM
First of all, Slackware doesn't break, even if you use --nodeps --force<nobr> <wbr></nobr>;-), so that's a bad comparison.
Second, for a non-trivial application, deps are dependent on the options (if I want an Apache without php, I don't need php libs<nobr> <wbr></nobr>...). There is no package manager that lets you do that, because you have to take the options of the provided package (which is either none or all, usually). You might not want that, especially if you're running more than 1 box.
Third, conflicting deps between packages. pkg x wants lib y, version 1, and pkg z wants lib y, version 2. But your pkgmanager typically just overwrites the lib (because why would you need more than 1 version of a lib?)
Fourth, to become a slightly less lame admin you have to be able to shoot yourself in the foot (frequently) in order to provide these much needed learning opportunities. Any dumbass can run 'apt-get update && apt-get upgrade'. And yell at devs when something breaks.
Fifth, for some reason or another, I always have trouble gettings my pkgs from official servers. And never for plain src. Security question: which would you prefer? You were running some critical boxen, right?

Full disclosure: Yes, I am _really_ fond of slackware. I am running 100+ slack boxen, all with (different) hand-compiled stuff. Call me hardheaded.

#

Re:best garbage management tools

Posted by: Anonymous Coward on February 23, 2007 02:46 AM
Wow you have to search many sites to find nonsens like this, you sound like a regular gentoo/ubuntu user. Distro´s like gentoo do have a garbage management tool because the distro uses all the memory on a single emerge sync blarp. That´s what i call a garbage management tool, can you tell me why a system should know one million packes when you obly should use 100 and so on. Slackware is simple to upgrade and that make the package management better.

#

Great article

Posted by: Anonymous Coward on February 21, 2007 07:27 PM
Great article, I've used Slackware, and thought it felt very "Linux". It gave me an impression that it was true to Unix.

I think that all packages should include metadata, a list of dependences that it use, then its up to the package manager utility to either implement dependency checking or not, and the user can choose the package management system he wants, and if he like dependency checking, he can use a package management system that does dependency, if he don't want dependency, he can choose one that does not.

I want my system to use latest software, and I think automatic update checking is good.

#

Did anyone ask Slackware users/fans?

Posted by: Anonymous Coward on February 22, 2007 04:29 AM
The reason Slackware uses a basic package system is: People compiles their own stuff from source.

There are packages for interested people but Slackware's policy is to provide a pure Linux system with everything at right place so even the purest newbie can take<nobr> <wbr></nobr>./configure approach.

Also the GCC etc being "old" is not the case, Slackware uses time tested, stable application versions and there is always a update opportunity without any makefile modifications at all.

For the interested, apt-get or RPM can be easily installed and they work fine too!

(Ilgaz on Slashdot)

#

Did anyone need to ask Slackware noobs?

Posted by: Anonymous Coward on February 22, 2007 07:14 AM
> so even the purest newbie can take<nobr> <wbr></nobr>./configure approach.<nobr> <wbr></nobr>...and stay purest n00b for years. Exactly what I observe.

Again, sorry for being offensive: it's not because I hate you, it's because you've missed something fundamental *and* confuse those who still have a chance not to.

PS: I have two friends who've been using Slackware since something like 1995 or 96, and the above thoughts aren't easy on me. It's really as much a brain damage source as *BSD community and "monolithic package full install" Red Hat's approach are.

--
Michael Shigorin

#

SlackBuild scripts

Posted by: Anonymous Coward on February 22, 2007 03:41 PM
IMHO, this is a nice article but SlackBuild scripts are really worth mentioning. I believe they provide the most flexible way of compiling packages the way _you_ like it. Besides, there are multiple repositories that provide "ready to go" scripts. For example (in no particular order):

<a href="http://slackpack.tripleg.net.au/" title="tripleg.net.au">http://slackpack.tripleg.net.au/</a tripleg.net.au>
<a href="http://kaneda.bohater.net/slackware/packages/slackbuilds/" title="bohater.net">http://kaneda.bohater.net/slackware/packages/slac<nobr>k<wbr></nobr> builds/</a bohater.net>
<a href="http://www.slackware.com/~alien/slackbuilds/" title="slackware.com">http://www.slackware.com/~alien/slackbuilds/</a slackware.com>
<a href="http://home.tele2.fr/solsTiCe/messlackbuilds.html" title="tele2.fr">http://home.tele2.fr/solsTiCe/messlackbuilds.html</a tele2.fr>
<a href="http://slackbuilds.org/" title="slackbuilds.org">http://slackbuilds.org/</a slackbuilds.org>
<a href="http://slackbuilds.rlworkman.net/" title="rlworkman.net">http://slackbuilds.rlworkman.net/</a rlworkman.net>
<a href="http://www.slackbuilds.net/" title="slackbuilds.net">http://www.slackbuilds.net/</a slackbuilds.net>
<a href="http://slack.sarava.org/slackbuilds/" title="sarava.org">http://slack.sarava.org/slackbuilds/</a sarava.org>
<a href="http://www.stabellini.net/filesystem/index.php?dir=sources" title="stabellini.net">http://www.stabellini.net/filesystem/index.php?di<nobr>r<wbr></nobr> =sources</a stabellini.net>
<a href="http://poiroud.free.fr/linux/slackbuild/" title="poiroud.free.fr">http://poiroud.free.fr/linux/slackbuild/</a poiroud.free.fr>

BTW, <a href="http://www.slacky.it/" title="slacky.it">http://www.slacky.it/</a slacky.it> mentioned in the article also provides build scripts.

#

Re:SlackBuild scripts

Posted by: Anonymous Coward on May 05, 2007 07:09 PM
Did someone try netpkg ?

Netpkg is a modern package manager for Slackware and Zenwalk.

#

Slackware package management

Posted by: Administrator on February 21, 2007 11:08 AM
I've been using Slackware since about 1997 and, true enough, very little has changed with Slackware's basic package management tools and I've seen a lot of posts belittleing Slackware's lack of dependency support, but I'd like to share my observations on that.

First, the thing I like about Slackware's package management is that is just works. It is simple and straightforward. Actually dependencies aren't that big a deal. Slackware comes with such an excellent collection of libraries and packages that, most of the time dependencies aren't even an issue. On the rare occasion that there is a library required that isn't already present, it is nearly always available from Linuxpackages.net. Or one can simply download the source, compile it and package it with minimal headaches.

I use a simple script (I think I got it from Dropline GNOME's repository, called find_missing_deps.sh, that checks for missing dependencies. One can also use ldd. It ain't that big a deal!

There are also some additional package management tools that come with Slackware in the extras/ directory that this article didn't mention. One is Slackpkg, a package manager that can download, upgrade, install and remove selected packages. Another is Slacktrack. It can be used to build packages from Slackware's '.build' scripts
or your own.

Another useful tool that can be downloaded and installed from LinuxPackages.net is Pkgcheck. It can check a package for correct structure and contains other utilites, instcheck and vlpcheck.
Anyway, Slackware's package management is simple and, IMHO, elegant.

And one of the beautys of Slackware's philosophy is nearly any GNU/Linux program can be installed from source, packaged, and installed, without any worries. It will work just as the author of the program intended without the nessessity of jumping through a bunch of hoops to get it to work that I've seen on most other distros.

Slackware rocks.


Best regards -

Chuck Bell

#

A look at Slackware's package utilities

Posted by: Anonymous [ip: 64.238.16.66] on August 01, 2007 08:01 PM
Thoroughly enjoyed this pointer, infact, was so inspired I've started using slapt-get and its fantastic!
Thanks for taking time out of your busy days to enlighten us Slackware lovers!

#

A look at Slackware's package utilities

Posted by: Anonymous [ip: 70.23.188.40] on January 04, 2008 05:54 PM
I've just started using linux I have tried all the major distros about ten total. I have been looking for the similarities and differences from what I can tell the main differences are the way they deal with installation configuration and packages. none worked 100% for me Slackware does so i think i will keep using it.

slackware's minimal approach to every thing means that it works when the automagic fails. For instance in MEPIS I screwed up my xorg.conf and MEPIS doesn't include any command line utils to configure !anyting! but if it only includes gui utils and the gui fails than how do u fix it? maybe u could manually debug xorg.conf but I am no 31337 h4x0r. so i tried slackware and it makes all the impossible, maby not easy but at least possible. i think this is evident in the package management as well.

so i am posting a question about package management in Slackware any comments appreciated. it seems, and I think I read some where that each tgz package includes all the libraries it depends on that make sense to include where as deb's don't. that is tgz implies (this is every thing u need to make this work) where as deb/rpm implies (this is the name of the thing u want and threw dependencies we can track down a complete package) do i have all that correct?

in concluding with a deb if a dependency is missed and the software fails to be installed properly they tell u what !u! should have downloaded to make it work in Slackware u tell the maintainer of the package what !they! should have included or that Slackware itself should include the lib. i think this is like having no CLI config tools for GUI configuration when all else fails Slackware still works in the case if tgz's u just install ones that work and when the packages are designed properly u don't need to check for dependencies. Its simple elegant and works 100% unlike the 10 other distros i have tried so far.

hope i got all that correct pls correct if not !Slackware ruleS!

#

How do you view installed software as the standard output in the terminal window?

Posted by: Anonymous [ip: 81.222.174.129] on February 22, 2008 09:55 AM
I mean there's the pkgtool utility. I'm not really sure but I hope the View menu item shows the packages already isntalled on my system.

Is there a way to list installed software from the command line?

#

This story has been archived. Comments can no longer be posted.


 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya