slapt-get is an APT like system for Slackware package management



slapt-get tries to emulate Debian's apt-get as closely as possible.


Quick Help

$ slapt-get --help
slapt-get - Jason Woodward <woodwardj at jaos dot org>
An implementation of the Debian APT system to Slackware
slapt-get [option(s)] [target]

--update - retrieves pkg data from MIRROR
--upgrade - upgrade installed pkgs
--dist-upgrade - upgrade to newer release
--install [pkg name(s)] - install specified pkg(s)
--remove [pkg name(s)] - remove specified pkg(s)
--show [pkg name] - show pkg description
--search [expression] - search available pkgs
--list - list available pkgs
--installed - list installed pkgs
--clean - purge cached pkgs
--version - print version and license info

--download-only - only download pkg on install/upgrade
--simulate - show pkgs to be installed/upgraded
--no-prompt - do not prompt during install/upgrade
--reinstall - re-install the pkg
--ignore-excludes - install/upgrade excludes
--no-md5 - do not perform md5 check sum
--no-dep - ignore dependency failures
--disable-dep-check - skip dependency check

useful slapt-get commands

Please refer to the documentation for slapt-get: man slapt-get, the HOWTOs at the VL Forum: slapt-get basics and gslapt basics or go to the slapt-get FAQ site for more advanced topics.

You may wish to try some of these slapt-get commands:

Slackware Packages 

VectorLinux is able to install Slackware packages. However, Slackware does not normally support slapt-get nor do Slackware packages do any dependancy checking. For this reason we do not recommend enabling any Slackware repositories in the /etc/slapt-get/slapt-getrc configuration file (or with gslapt, Edit, Preferences, Sources, Add a Source). The default slapt-get configuration file will enable the user to download and install Vector packages only. Slackware packages which are non-system packages will probably work fine with VL but you may have to install all the dependant packages first and there is no guarantee the package will work properly. If you do decide to load a Slackware package please ensure you download packages built for the correct version of Slackware.

slapt-get: Verifying checksum signature failed 

I get the following error when using slapt-get

Sources failed to download, correct sources and rerun --update

Seems that it is because of the failure verifying the checksum signature:

$ slapt-get -c slapt-getrc.slacky --update
Retrieving package data []...Cached
Retrieving patch list []...Done
Retrieving checksum list []...Cached
Retrieving checksum signature []...Cached
Verifying checksum signature []...Not Verified
Sources failed to download, correct sources and rerun --update

My distro don't have the slapt-get man page installed, and I can't find the slapt-get man page on web. So I don't know how to fix it. Please help.

PS. trying to add the '—no-md5' to the command line doesn't help.

slapt-get: Verifying checksum signature failed 

  1. Did you remember to run 'slapt-get —add-keys' after adding the new source?

  2. Are you using the latest slapt-get version? Should be 0.9.12d

  3. Are you able to access the repository from your browser?

Just for reference here is my file:

# See /usr/doc/slapt-get-0.9.12d/example.slapt-getrc
# for example source entries and configuration hints.

documented on: 2008-06-26, digger95

slapt-get: Verifying checksum signature failed 

> 1. Did you remember to run 'slapt-get --add-keys' after adding the new source?

That IS the reason. Problem solved. Thanks, Dig.

% slapt-get -c slapt-getrc.slacky --add-keys
Retrieving GPG key []...Cached
GPG key successfully imported.

% slapt-get -c slapt-getrc.slacky --update
Retrieving package data []...Done
Retrieving patch list []...Done
Retrieving checksum list []...Done
Retrieving checksum signature []...Done
Verifying checksum signature []...Verified
Retrieving ChangeLog.txt []...Done
Reading Package Lists...Done

documented on: 2008-06-26, xpt

Slackware Package Management Best Practices

I was wondering if the more experienced members would not mind sharing the way that they handle/manage packages on their system. Obviously when a Slackware package is available, using installpkg is the logical choice. I also use slapt-get to keep my system up to date with the latest security patches. . .

It'd be nice to have everything in a centralized place so I can just use pkgtool to manage everything. Should I just learn to write SlackBuilds scripts, or are there other alternatives?

Slackware Package Management Best Practices 

Here's what I do:

Hope this helps. Looks like the only thing you are really missing is src2pkg or trackinstall/checkinstall.

Last edited by jelaiwang : 04-16-08

Slackware Package Management Best Practices 

> > if you have already compiled your software you can create the package
> > directly with "trackinstall" (comes with src2pkg). You don't need to
> > re-compile it by running src2pkg.
> I remember gnashley saying somewhere that people should use src2pkg and not
> trackinstall as src2pkg does more stuff

there are several good reasons to use src2pkg instead of trackinstall. Mainly because it will keep a better record of any special options you have passed to the configure script, but it is also very helpful when the sources can't be configured and compiled with the usual './configure && make && make install' trio of commands. It is also able to handle sources that use scons, jam, imake and cmake -usually without any help at all. There are only a couple of cases where trackinstall may be able to create a package and src2pkg can't -such as with some pre-compiled binaries which use an interactive installation script.

I'm glad to see that jelaiwang mentioned using src2pkg instead of rpm2tgz — src2pkg does a much more thorough job of converting binary packages from rpm or deb format since the resulting package conetent id subjected to all the usual src2pkg conetent checks — like being sure that directories have the right ownership and permissions, plus stripping the libs and bins, compressing the man-pages if needed and any other special steps which you ask for. rpm2tgz has been around a long time and is part of the official Slackware release, but it is really not adequate for converting *binary* rpm packages, though it works fine for converting srpm's — that is rpm source archives. If you point src2pkg at an rpm source archive, it will unpack it and try to compile it like a regular tar.gz/tar.bz2 source archive.

My advice about keeping your system up-to-date is to just check the Slackware site from time to time for patches to your installed version, or subscribe to receive the security upgrade notices. Then just manually download the packages and use upgradepkg to install them. Trying to keep up with 'current' is not a good idea if you like to keep your installation stable or if you have other things to do besides continually messing with your system.

documented on: 04-17-08, gnashley

Slackware's package management from a Debian user point of view 

When I was using Redhat, I found that many tools that I wanted did not come from the official repository. Rpmfind was the top site that I visited, but even so, I sometimes experiences difficulties installing packages, because,

After I switched to Debian, the package installation hassle was over. I never ever had any problem installing the tools that I want under Debian. Housing cleaning, i.e. removing unwanted tools, is easy as well.

For Slackware,

If you want to find the easy you have in Debian from Slackware, you have to find very hard since the dependency handling is not officially supported or even encouraged. Luckily, there are unofficial tools, but, which one to choose? Many people prefer slapt-get in the Slax community, fewer talk or even know about swaret, but the reality is,

That brings more complexity to choosing the dependency handling tools. And since the official package repository is so small, you have to rely on some unofficial ones if you want better luck to find the packages for the tools you are looking for. slapt-get FAQ suggests 3:, CollegeLinux and VectorLinux. Among them and others, which one is better?

My short answer is:

The conclusion is base on the following collected articles.

documented on: 2008-05-17

slapt-get & package dependencies

First of all, slapt-get does not provide dependency resolution for vanilla Slackware packages (ie, official Slackware packages that come with the distribution).

However, slapt-get does provide a framework for dependency resolution for packages that follow the Slackware package format, while still being backwards compatible. This information is stored in so called meta files within the package.

Packages supporting this framework can be found at, along with several Slackware derived distributions such as CollegeLinux (starting with 2.5) and VectorLinux (starting with 5.0).

Also, Stefano Stabellini has created a PACKAGES.TXT that contains the dependency information for Slackware packages without modifying the actual packages themselves. This can be used as a slapt-get source to pull the packages from official mirrors. Read more about it at Stefano's page:

Slackware Linux

September 24, 2003 contributed by Ladislav Bodnar

Slackware's package manager does not have the ability to resolve dependencies. The MPlayer experiment started with a trip to LinuxPackages, where I located and downloaded the necessary package, then executed installpkg:

installpkg mplayer-1.0pre1-i686-2rob.tgz

Although no errors were reported during installation, MPlayer failed to launch due to missing libraries. Back to LinuxPackages to download alsa-lib, lame and libdvdread (the dependent packages were clearly listed on the MPlayer download page), before installing them with installpkg. This has satisfied all requirements and MPlayer was ready for action.

There are three third-party packages that handle Slackware package updates - these are swaret, slackpkg and slapt-get. Both swaret and slackpkg have now been officially included in the "extra" directory of Slackware Linux, but between the two of them only swaret has the ability to resolve dependencies, while slackpkg is generally used to keep a Slackware system synchronized with the "current" branch (i.e. development branch, equivalent to Sid, Cooker or Rawhide). At this point, it is perhaps interesting to note a recent comment by Slackware's creator Patrick Volkerding, which indicates that not everybody thinks highly about advanced package management tools: "I'm not a big believer in automated dependency handling."

As with all other distributions in this experiment, I wanted to upgrade a vanilla Slackware 9.0 installation to the latest available development version, which at the time of writing was Slackware Linux 9.1-beta2. This can be done with Slackware's native tools, but the process is fairly involved, it requires manual download of all upgraded packages, which then need to be upgraded with upgradepkg in a certain correct order. After downloading and installing swaret, the same could be achieved with two commands:

swaret --update
swaret --upgrade -a

Again, the process took time, but completed with no errors. Several newly upgraded packages required extra packages to satisfy dependencies and this is the only place where user intervention was called for to confirm the action. But the overall experience was very similar to upgrading Mandrake, except that it required a third-party tool.

Overall score (2 points were deducted for having to use a third-party package manager): third-party package installation: 5, distribution upgrade: 7.

Note the article not only covers Slackware, but also all major distros.


To conclude this lengthy and time consuming experiment involving package installations and distribution upgrades, we have two clear winners - Debian and Mandrake. Debian is hard to beat when it comes to overall convenience, but Mandrake has made a lot of effort and its urpmi package management and underlying technology has just about succeeded in catching up with Debian's. The other three distributions have a long way to go. Red Hat is currently in a major transition and the question of package and distribution upgrades is probably being addressed as I write this. Slackware is easy to upgrade with swaret, a tool which will be included in the upcoming Slackware 9.1, but it doesn't handle installing packages from third-party repositories. As for SuSE, it falls short of all other distributions. YOU has a pleasant interface and it works extremely well within its official package set, but as a software management tool, it has too many shortcomings to compare well with either apt-get or urpmi.

Swaret and slapt-get from my point of view

by: Anonymous Coward on October 20, 2006 04:06 AM

I have used both Swaret and slapt-get to automate downloading and installing Slackware packages. I don't think any of them is specially good, but I use slapt-get as the "less bad" of the two. I'll highlight the good and bad points of each tool, from my point of view. Also, take into account this information belongs to the stable swaret release. I think a new version is being worked on, and it's in Perl IIRC.


[Good] Checks GPG signatures instead of MD5 checksums. [Good] Checks binary dependencies without using any additional information. This is quite useful. [Good] As easy to use as slapt-get. [Bad] It's a shell script. Very big. Very, very slow. slapt-get uses much, much less CPU. [Bad] I didn't find a way, and let me know if there's one because I truly tried to find it, of automatically downloading and installing patches for the installed packages. You can either answer manually or install all of them, including the ones belonging to previously not installed packages.


[Good] Written in C and it's much faster. [Good] It has the patch behaviour I commented previously, that swaret seems to lack. [Good] Keeps directory hierarchy in downloaded packages. [Good] Has the option of removing local packages not present in the remote side (good for people using -current, to clean the package tree from time to time). [Bad] Doesn't detect binary dependencies. [Bad] Doesn't check GPG signatures. [Bad] I don't like the output format. It's similar to the one from apt-get. Swaret's output format isn't beautiful either, but I like it better.

Note the article is wirtten in year 2006. Now Swaret is written in Perl. So the first [bad] does not hold any more. and the second [bad] is controversial even by then.

Swaret and slapt-get from my point of view 

You must have been doing some thing wrong. Swaret has never defaulted to functionlike that in my experince. IT has always only upgrade installed packages only. Just run swaret —upgrade -a to upgrade all installed packages. It does not install any non-installed packages.


Swaret and slapt-get from my point of view 

It all really depends on whether you set the VERSION to the version you are running or current.

Current doesn't have any patches; they just become the new package. By setting the version to 11.0 (or whatever version is installed) and using the upgrade command, it looks at what packages you have installed (by referencing the<nobr> <wbr></nobr>/var/log/packages directory) and downloads available patches for installed apps.


Swaret and slapt-get from my point of view 

> [Bad] Doesn't detect binary dependencies.

Slapt-get can actually check for dependencies if a file called slack-required is in the install directory of the package. It can also resolve dependency conflicts based on the contents of slack-conflicts. "Official" Slackware packages do not include either of those files in the package. That's why there is no dependency checking for "official" Slackware packages.

With that said, however, slapt-get WILL check for dependencies in packages made by some Slack derivative distros like VectorLinux. It will also check for dependencies in packages distributed through

by: Administrator on October 21, 2006

Compare distros, Debian vs Slackware

Small number of official (vanilla) packages. In most cases, manual compilation of many packages will be needed. Sometimes there is an alternative being unofficial Slackware packages downloadable from project's pages or LinuxPackages and

Slackware's package management system is based on the simple tgz packages which do not contain any information about dependencies. Additional unofficial packages can be found on LinuxPackages and These packages are in extended tgz format — so that they can contain meta-information about dependencies (but unfortunately in each case). There are two programs that can use this information: swaret and slapt-get (together with graphical frontend GSlapt). Many additional tools has been designed to improve Slackware package management — from tiny scripts to full systemy portow (Emerde, pkgsrc, Portpkg). It is also possible to create own packages using checkinstall utility.

Obtaining And Adding Software

The easiest way to obtain software for your custom Slackware distro is using a site called Linux Packages. Linux Packages has a wealth of slackpacks, submitted by several members of the Slackware community.

A look at Slackware's package utilities 

By Mayank Sharma on February 20, 2007

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


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.

documented on: 2008-05-17

Third-party Repositories

It seems to me that is the most popular third-party repository. And my question is how to use it with slapt-get?

I know from

If I am to use the "NYI New York Internet" mirror, I would set Slapt-get to SOURCE=

But when it comes to practice, I have the following questions.

In this case, would slapt-get search find those 2 packages for me? If not, what should I do?

All in all, what's the best practice using third-party repositories?

Third-party Repositories is a more reliable source than in my opinion. I know nothing about slapt-get or slackpkg, so I can't be more help than that — I will just say that has some poorly-built packages with questionable dependencies that have the possibility to bork your system. Although there ARE some reputable packagers at, you would have to find out which ones are reputable and only use their packages — and that's a lot of work, and not very convenient when using slapt-get. has a large repository with well-built packages that all include a SlackBuild so you can see how they built it or compile it yourself using their SlackBuild, if you want.

I trust, Alien Bob's repository ( and rworkman's repository ( 100%, and 50% (though I'm a pessimist and I always just use the SlackBuilds from and not their pre-built packages). If you want huge repositories with every package you could possibly want, Slackware isn't the distro for you — some packages won't be available anywhere and will need to be compiled (by you) from source. That being said, with the nice repositories listed above, that would be an exception instead of a rule, but just be warned.

documented on: 2008-05-18, T3slider

Third-party Repositories 

The only ready made packages that I will use is rworkman's, Alien Bob's, & sometimes

documented on: 2008-05-19, slackass

Third-party Repositories

  1. . .I have also in the past downloaded from but only from one particular packager who consistently does good work. Never had a problem with his packages. . .

May I know who the packager is? Who else do you think might be good as well?

2nd, do you download from web or you use slap-get to download the package and all its dependencies? If so, how do you do that?

Third-party Repositories 

I no longer use to be honest. I primarily use slackbuilds, src2pkg, or download ready-built packages from the official repo, alien bob or rworkman. However that's not what you're asking, so…

If you want to download packages and get dependency resolution as well, I would trust only. They build good packages and their dependencies (so far) seem on target. Nothing has downloaded and installed to my machine that made me scratch my head anyway. You can use either one of the following with slapt-get/gslapt: (main site) (u.s. mirror)

Before I started using slapt-get though I learned to do my own packaging and dependency handling, so I already have a good idea what should or shouldn't be downloading to my machine, and I also compare what's going to be downloaded with what's already in /var/log/packages to make sure nothing gets overwritten.


How Do You Install Non Officials Packages

I gave several options and i think it already represents the most common way to install non official packages

You can choose more than one answers for this poll

Willy Sudiarto Raharjo

How Do You Install Non Officials Packages

In just a day, the vote has got a huge response from Slackware users around the world. So far, 72 peoples have vote for it and most of them voted for It seems that including is the correct decision as it has so many users worldwide. I still believe there are still a lot of users out there. So please came by and vote for it.

Willy Sudiarto Raharjo

How Do You Install Non Officials Packages

Thanks to everybody who contributes to this votes as it claimed as the highest record on my blog (184 voters). The question was "How Do You Install Non Officials Packages?" and the results are as follow:

All of my options are voted, but as usual, we always have a winner, so this month poll's winner is the third option, Get from

FYI, is an Italian Slackware community that has wide community (if you are looking at the poll results above, you will see what i mean) and it's not coming just from Italian people. They gave SlackBuilds script to compile the source code and turn it into tgz packages which is the native Slackware format so that you can easily manage them using installpkg/upgradepkg/removepkg commands. Although the website is build using Italian language, most of the package name are still reserved in English, so i guess you won't find it hard to find the packages you are looking for.

I know that the options listed here are not the only ways of installing a package in Slackware Linux, but i guess it can accommodate the most common ways to install third party packages.

Willy Sudiarto Raharjo

documented on: 2008-05-19

What is Your Favorite Package Management

The question is What is Your Favorite Package Management? and i gave 6 options, but at the end, only 4 who was voted by the audience and here's the results:

  1. Pkgtool 45 (42%)

  2. Slapt-Get 29 (27%)

  3. Slackpkg 20 (18%)

  4. Swaret 12 (11%)

  5. SlackMan 0 (0%)

  6. GetPKG 0 (0%)

The winner is Pkgtool with 42%, the default Slackware package manager tool. It seems that people still like the default application, even though it's lacking of automatic download, automatic dependency solver, and many more compared to automatic tools such as Swaret and Slapt-Get.

The runner up is Slapt-Get, with 27%. Even though it's not an official package in Slackware, people seems to like this tools, as it can automatically download the updates and install it for you. Even so, it's best to use this tool for -Stable release only. DO NOT use this kind of tools when you are playing with -Current and you KNOW what you are doing with it. I have seen many people screwing their system just because they use automatic tools like this and misconfigured them.

Willy Sudiarto Raharjo

documented on: 2008-05-19

Reconsidering Vector

April 21, 2008

I noted in my entry yesterday that I'm thinking of doing a low resource slackbuild. Part of the reason for that is my experience with both Slackware and Vector Linux. Not to mention my experiences with Damn Small Linux in both traditional and frugal installs.

Now that I've had a few months to use Vector, I've found several things that cause me second thought about recommending it. I'll check the Vector forums later today to see if these are issues others have dealt with. Last time I went to the Vector site, it had been hacked (search my vectorlinux category for screenshots).

(Edit noon CDT: I've been to the Vector forums and I'm awaiting approval to post in their forums.)

First, upgrade options in gslapt have been disabled. This means users are unable to upgrade their systems using the default package management system's GUI. I haven't found out yet if it's still possible via slapt-get or other parts of pkgtools. I can't blame Vector for conflicts due to using different repositories, but Slackware and repositories are NOT suitable across the board for use in Vector. I found this out when trying to update OpenSSH and getting an error from SSL not matching the version against which SSH was compiled. Easy fix to revert to the older version. I still haven't found the security update for OpenSSH in Vector's repositories, though. Which is the underlying issue for me — security and upgrade-ability.

Second, the base packages are very bloated. I appreciate the desire to make the system usable by everyone without having to add font packages, but the tools for using the included Ethiopian fonts aren't included. If you're not going to include the tools to use the fonts, don't bloat up users' hard drives with 50+ MB of fonts! Geez. Add to that the dependencies which many packages have been compiled — e.g., requiring samba to run mplayer. Little thought given to users who may not install/keep samba. Like the security issue noted above, that means more work compiling myself. And I was trying so hard to not do that on this ancient laptop.

Also, the included wallpapers and icons aren't what I consider light or fast. They're pretty heavyweight compared to other options. This is noteworthy when considering the 82 lines in .jwmrc with icons — some of them being scalable, some of them being quite large, and the menu icon itself being over 40kb. All of that crap loads to RAM and causes performance issues as jwm has to scale the various and sundry icons. I realize my own jwm configuration is spartan and probably not to most users' tastes, but there has to be a reasonable approach to this. And I'm not arguing for removal of all icons from .jwmrc, just use sensibly-sized icons that don't cause users to use the same amount of RAM to use jwm as they use for Xfce!

Third, there are several bugs to be sorted out. For example, the setconsolefont script is broken (line 41):

/usr/bin/setconsolefont: line 41: $REPLY: ambiguous redirect
putfont: KDFONTOP: Operation not permitted

While that's not particularly serious (setfont /path/to/consolefont), I've had several getty issues on my laptop. Suspend/tuxonice doesn't work and causes me to lose all video whether in X or console if I go idle. If I kill X, I don't get any video input — just a blank screen. I can blindly type "startx" to get back to X but can't view any console output.

Fourth, another sort of minor thing that isn't very minor: I also noticed that my wireless router light would continue to flash for a few minutes after I shut down. I found that /etc/wireless/interface.conf listed INTERFACE="wlan0" instead of eth0, which is where my interface was set up using VASMCC — Vector's own tool.

There are a few other issues that I've wrestled with but these are the ones that come to mind. While I still think Vector is commendable and headed in the right direction, I can't recommend it to inexperienced users. I also think in some ways experienced users wanting a Slackware-based desktop would be better served using Slackware in the first place. The packages are going to be about the same. I've already recompiled more things than I wanted to, and here I am thinking of removing X altogether and rebuilding the system to pare down the bloat. I just think Slackware's minimal install with a few select packages is a more sensible choice than Vector for someone wanting a low-resource system.

I intend to check out Vector's lighter project soon. Maybe that will be better, maybe not. I don't think it's adequate to offer jwm and/or fluxbox and call it "light." There's more of a need for a paradigm shift to it than merely remixing apps and window managers. Anyone can do that and the world doesn't need more sub-distro remixes masquerading as "new" distros. Will it actually use distinct, separate packaging with minimal associated bloat? Or will someone ostensibly update to full-blown Vector when installing something from the repo because the apps aren't compiled with forethought to keeping the system as small and unbloated as possible?

If it's the latter, no deal. If not, there won't be any need for me to continue with my low resource slackbuild. Or to be a little more cautious about recommending Vector without qualifying it.

EDIT: I resolved the issue with losing ttys after killing X by modprobe vga16fb (I don't need framebuffer before X but I do after?). I'm still sorting out tuxonice. Or giving up on it. I'm also still waiting for activation for the Vector forums. Registered once, just hit my second 'resend activation code' button today.

documented on: April 21, 2008, lucky

Reconsidering Vector 

> Have you looked at Zenwalk Linux? ([]

Yes, I tried the (last? only?) beta for 5.0 before the RC was released and before trying Vector. Same problem I'm complaining about Vector, too — the packages really aren't built with lower-end users in mind. The two aren't that different. Both are Slackware-based, both have similar default mixes of apps, both use Slack packaging.

Please correct me if I'm wrong and Zenwalk packagers are more inclined to reduce/minimize dependencies than to add in every possible feature.

Zenwalk core edition is on my list to try as a base for the lower resource build above that (choice is between that, Vector without X, Slackware current minimal, or start from scratch).

documented on: April 21, 2008, lucky

Zenwalk & DW awarded

> Ladislav from DistroWatch has awarded 200 EUR to Zenwalk...

It's not necessarily a bad thing to donate to Zenwalk, but for me Wolvix is much more zen.


More info:

In short, Slackware-related, DW has awarded: Vector, NimbleX and Zenwalk, but no one can get the current sources for Zenwalk (if they're hidden, they're extremely well hidden!). In the meantime, Wolvix, another installable LiveCD based on Slackware, was not awarded anything!

Ladislav, the next time please do your homework!

documented on: 2008-01-07, Beranger

Finding Slackware packages

> which slackware package contains the "xosview" tool?
> how can I know that?

xosview is not part of the standard slackware repository … the link above is to the source code to compile for your system …

to see/search all packages in slackware find a slackware server/mirror and look at the changelog.txt

in or

you can also find other slackware support sites like or

one other notable slacware package support site

documented on: 2007-06-15, Guest