SlackBuilds: Installing Software on Slackware (2026)

✅ Covers Slackware 15.0 package management — Last updated: September 2026

Slackware doesn't have a package manager that resolves dependencies for you — no apt install pulling in everything a package needs automatically, the way you'd expect coming from a apt, dnf or pacman background. That's not a missing feature, it's a design decision the project defends explicitly, and once you understand why, the actual tools (pkgtool, slackpkg, and SlackBuilds) make a lot more sense.

Practicing this on a live server, or need one to follow along? See our comparison of the best Linux VPS hosting providers for 2026 if you need a Linux box to work on.

Why Slackware Doesn't Auto-Resolve Dependencies

This is the single biggest adjustment for anyone coming from another distro, and Slackware's own documentation lays out the reasoning directly:

• Administrative control — you know exactly what's installed and why, instead of a resolver silently pulling in packages you didn't ask for.
• Security accountability — an auto-resolver can install a package with a known bad security history without you ever reviewing it.
• No silent conflicts — automatic resolution can pull in something that conflicts with what's already installed and break working software.
• No dependency bloat — if you recompile something with reduced functionality, an auto-resolver would still force-install dependencies that functionality no longer needs.

In practice this means you decide what gets installed, which is also why Slackware's own installer recommends a full install for most users — it sidesteps the whole problem by installing everything up front instead of chasing dependencies package by package later.

Slackware's Native Package Format

Slackware packages are just tar archives with a Slackware-specific structure, distributed under one of four extensions depending on the compression used:

pkgtools: The Core Package Commands

Every Slackware install ships pkgtools, a set of dedicated command-line utilities rather than one all-purpose tool:

Installing a package you already have locally is a one-line command:

installpkg wine-2.5.6-x86.tgz

slackpkg: Official Packages and System Updates

For anything coming from Slackware's own servers — including security updates — slackpkg is the tool:

slackpkg update
slackpkg upgrade-all

It handles version upgrades too, without a full reinstall — but if you're jumping a major version, read UPGRADE.TXT on the install media first. It specifies the correct install order to avoid breaking the system mid-upgrade.

SlackBuilds: Building Software Slackware Doesn't Package Officially

This is where Slackware handles the software that apt or dnf users get from a repository search — except instead of downloading a pre-built binary, you download a build script and compile it yourself against your own system.

Every officially supported Slackware package actually ships with its own SlackBuild script and source code, right there on the install disk — so the build recipe for anything in the base system is already something you can inspect and modify. SlackBuilds.org extends that same model to third-party software: user-submitted, community-tested scripts, each bundled with:

• The build script itself
• License information
• .desktop files and icons, where relevant
• A .info file listing the version, source download URL, MD5 checksum, supported architectures, and script author

Running a SlackBuild compiles the software from source and packages the result in Slackware's own format — so it installs, upgrades and removes cleanly through installpkg/upgradepkg/removepkg like anything else, instead of leaving stray files scattered outside the package system the way a manual ./configure && make install would.

sbopkg: Managing SlackBuilds Without the Manual Steps

Running SlackBuild scripts one by one works, but sbopkg automates the process: it syncs with the SlackBuilds.org repository, lets you queue scripts and set a build order, supports customizing a script before it runs, and can build-then-install in one pass instead of two manual steps. If you're managing more than the occasional package this way, sbopkg is worth setting up early rather than scripting the loop yourself.

Third-Party Tools That Add Dependency Resolution

If Slackware's manual model genuinely doesn't fit your workflow, a few unofficial tools bring dependency resolution back — worth knowing they exist, even though they step outside how Slackware is designed to be used:

• slapt-get / swaret — apt-get-style tools: point them at a repository, they fetch and install from it. swaret additionally attempts dependency resolution.
• slpkg — computes dependencies automatically and figures out what's needed to install a given package, closer to a traditional package manager's behavior.

None of these are officially maintained by the Slackware project — they're community tools, and using them means opting back into automatic resolution with the trade-offs described above.

Which Installation Method Should You Use?

Frequently Asked Questions

Why doesn't Slackware resolve dependencies automatically?

It's a deliberate design choice, not a missing feature — the project cites administrative control, security accountability, and avoiding silent package conflicts as the reasons. You decide exactly what gets installed instead of a resolver doing it for you.

What's the difference between pkgtool and slackpkg?

pkgtool is a menu-driven front end to the core package commands (install, remove, view) for packages you already have. slackpkg specifically talks to Slackware's official servers to install packages and apply updates from the distribution's own repository.

Is compiling software manually a bad idea on Slackware?

It works, but it's discouraged in favor of building a SlackBuild script instead — a SlackBuild produces a real, trackable Slackware package that installs and removes cleanly, where a manual make install typically doesn't register with the package system at all.

Do I need sbopkg, or can I just use SlackBuilds directly?

You can run SlackBuild scripts directly with no extra tooling — sbopkg just automates syncing the repository, queuing multiple builds, and installing the result, which matters once you're managing more than a couple of packages this way.

What does the .info file in a SlackBuild actually contain?

Version number, the source download location, an MD5 checksum to verify the download, supported architectures, and the script's author — everything needed to verify what you're about to build before you run it.