Precompiled third-party packages

Many Slackware users avoid installing unofficial precompiled packages on their systems. I find this understandable, since there has never been (IMHO!) a big and trusted repository for third-party packages. I used to install just a couple of packages provided by AlienBob (like LibreOffice and some of its dictionaries) and then compile everything else from SlackBuilds.org.

Not surprisingly, my desktop computer serves, among other things, as a machine dedicated to package building. I have virtual machines (VM) with clean installs of Slackware x86 and x86_64, where I check the SlackBuilds I maintain. For my own use I normally build what I need on the x86_64 VM and then install the generated packages on my other computers. This saves time and avoids the problems that may occur when building on a multilib system. Whenever updates are available from SBo (and this happens often), I use the excellent sbopkg tool to upgrade packages. Also, I find it a good practice to recompile any packages with updated dependencies against the new versions. This presents me with the confusingly tedious (for me) chore of tracking packages that may need to be recompiled. Anyway, by using my own custom queue files, I have managed to successfully go around this problem in a semi-automatic way.

This approach works very well, as it’s technically simple and grants me control over my system. I have gotten the habit of exchanging packages between computers over SSH on my home network. Sometimes I even carry packages on an external hard disk if I have to travel abroad. The reason is that if something happens with my system I can quickly restore my working environment. Using my precious packages. I believe I could also set up my own home server to host the packages for my own use.

Wait… what?

I believe it was this last thought that made me reconsider the way I had been doing things.

Compiling can be really time consuming, even on modern hardware. For people with older machines it can be a real pain. In addition, having a -multilib system occasionally leads to problems at compile time. Therefore, good quality third-party packages seem like a preferable option to compiling from source. The relatively new, but notable, SlackOnly project aims to cleanly build all entries from SlackBuilds.org using the slackrepo tool. For packages that have optional dependencies, the slackrepo hint files are consulted. Whenever a package is updated, all packages that directly depend on it are recompiled, too.

I think that SBo is the best source for creating a third-party packages repository for Slackware. SBo covers a vast variety of software, providing a broad selection of ready-to-build programs and libraries from a single place. Having these programs and libraries already packaged presents a very convenient choice. I can think of three options for users:

1. Users who prefer to have total control at compile time over optional features will use the scripts at SBo, just as before.
2. Users who want to quickly install software will grab the SlackOnly packages.
3. Users can install some packages from SlackOnly and build from SBo only the ones they want to compile against specific optional dependencies or features.

Point 3 is what suits me best. I installed from SlackOnly the packages that I was happy with and then compiled from SBo the ones that I wanted to be exactly to my liking. This provides both speed and flexibility, by combining the strength of points 1 and 2.

SlackOnly is a one-man-project, maintained by Panagiotis Nikolaou (Panagiotis Nik at LQ). If you are interested to join and help or provide a mirror, please contact him at panos.mdma ат gmail.com. Also, he will appreciate any feedback.

I am not affiliated with SlackOnly, I just like the idea of the project and have exchanged several emails with the maintainer. I have written three previous posts about SlackOnly:

SlackOnly as a main third-party repository (2015-11-02)

Slackonly: an update (2015-05-16)

Slackonly: packages built from SBo (2014-04-12)

---