Member Avatar for tallship
tallship 16 Newbie Poster

I was urged to do this write up in the form of a new thread... so here we go!

---

Installing from source on Linux is indeed about as easy as it gets (Much easier than installing a wYNd0z3 app). There are excellent tools to accomplish this in Slackware Linux - fresh out of the gate from a new install.

Slackware includes an army of libraries, development tools, and languages (none of this hunting down the *-devel.rpm's) straight out of the box. It has a wealth of applications available to install at the flip of your wrist too.

I covered the basic installation of packages in a earlier article, and this time, we'll go up metaphorically from what Redhat/Fedora/CentOS would call 'rpm' to 'yum' - as it relates to Slackware of course.

Slackware does support RPMs, but you should probably consider that a second rate, or deprecated supported feature - stick with it's native and community supported tools and you'll never look back at those other Linux distros again.

Now, Slackware doesn't just do source like this, although it certainly can and does when you want it to:

# wget [url]
# tar zxvf source.tar.gz
# cd source
# ./configure; make; make install

As I've covered in the previous article, you can simply use *installpkg* to install a package, but software not included with the standard distribution is kept on the upstream developers sites themselves, so we use a repository called SlackBuilds.org.

SlackBuilds.org provides us with what we call, you guessed it, SlackBuild scripts. You download the SlackBuild, download the source, run the SlackBuild script, and not only does it compile the source, but it drops the application very nicely packaged binary - ready for you to install at the speed of lightning with: # installpkg <package_name> or if it is an upgrade to a package that is already installed on your system: # upgradepkg <package_name> and if you want to roll back to the previous package with the flick of a switch: # upgradepkg <new-package_name>%<previous-package_name> And finally, if you want to remove that package from you system: # removepkg <package_name> Wow! That's clean and simple!

But there's even another abstraction layer of convenience on top of that! sbopkg.

sbopkg goes even further, You invoke it like you would apt-get or yum - except that apt and yum simply fetch the binary package and install it, while sbopkg fetches the source, the SlackBuild, runs the SlackBuild, which compiles the source, then either installpkg or upgradepkg is automatically invoked once you have automatically created the binary package totally optimized for your particular system - all automagically!

It goes like this: # sbopkg -i <application_name> All done!


"Wait!!! Fetched, compiled from source, bundled into a package you can take with you on an airplane, and installed on my system - right there in my KDE menu???"

YES! It really is that simple with Slackware Linux :)

You can get Slackware at http://Slackware.com - it is indeed the oldest, and arguably most stable Linux distro there is, and you should be running it for your most mission critical applications at your work and in your home.

I hope that helps!

Kindest regards,


Bradley

Registered Linux User #190795

- "Ask Bill why the string in [MS-DOS] function 9 is terminated by a dollar sign. Ask him, because he can't answer. Only I know that." - Dr. Gary Kildall.

Edited by tallship because: maek pritty
  • 1 Contributor
  • 0 Replies
  • 194 Views

Dani AI

Generated

Good, practical rundown from . Slackware’s model of building a binary package from source preserves system cleanliness while giving the benefits of locally-optimized builds. The convenience layer provided by sbopkg and community SlackBuild scripts combines reproducibility with the kind of automation people expect from apt/yum, but it still relies on a few simple practices to stay robust over time.

Recommended workflow (high level): pick the appropriate SlackBuild and read its notes; obtain the upstream source and verify checksums/signatures; build the package in a dedicated, non-root build area (use fakeroot where appropriate) so the result is a proper Slackware package; archive the binary package in a local repository for reuse across machines; install and test using the native package tools so the package database remains consistent. Keeping the original SlackBuild and any small local patches under version control makes future rebuilds trivial.

Common failure modes and fixes: consult the SlackBuild’s dependency list first—missing build-time libraries or header packages are the usual culprit. Capture and review the build log to find the failing step; if a configure or compile option is required, note it in the SlackBuild before rebuilding. For runtime problems check dynamic library versions and linker paths, and revert to the archived binary package if the new build breaks an important service.

Operational notes and cautions: prefer packaged installs over one-off “install from source” copies so removal and rollback are manageable. Maintain a private binary mirror of built packages for quick recovery and repeatable deployments. Review SlackBuilds before building (patches and flags matter), verify upstream checksums, and avoid building as root except when the packaging step explicitly needs it. These small habits keep the Slackware source-to-package approach safe, repeatable, and production-ready.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.