Slackware 15 — 2
For me the next step with updating Slackware is compiling non stock packages, most of which are from slackbuilds.org. In bygone days when Slackware was released on average every nine to twelve months and system changes were incremental, I rebuilt third party packages only when something broke or a newer version of a package provided compelling new features. Considering the more than five year development cycle of 15.0 I decided to purge and build packages fresh.
There are third party tools to bulk manage additional packages, but I do not mind methodically building each package individually. There is a degree of satisfaction watching the collection of packages grow. Important is that compiling individually helps me remain familiar with the underlying system.
In these days of multi-core CPUs, gobs of RAM, and virtual machines (VMs), compiling packages tends to proceed in a pleasing manner. Unlike the days of running Linux on a single core CPU with 256 MB of RAM, building a package on modern hardware often is complete in a minute or two. Of course, there are a few beastly packages requiring much more time despite the modern computer muscle.
With each Slackware release there are underlying changes in the operating system, libraries, and compilers. Some packages fail to build. This is frustrating and a notable reason I dislike updating systems. Unlike developers and enthusiasts, I prefer older versions of some software. Newer does not mean better. When a package fails to build I have to sleuth around the web to discover why. This is not fun because search engines have grown progressively worse. Sometimes I find solutions. Sometimes I am required to use a newer version. One way or another these build failures require time to resolve.
To build 15.0 packages I used a new 15.0 virtual machine (VM) created for testing the update process. That approach allowed me to keep the underlying host on the stable Slackware 14.2 and remain online to research problems. To improve compiling speed I configured the VM with 4 cores and 8 GB of RAM.
There were several compiling speed bumps.
I use Goldendict daily. The software compiled fine but failed to function correctly. The default software includes no dictionaries. Yet on my 14.2 system there was a dictionary. Eventually I figured out that a long time ago there was a goldendict-wordnet package. I still had a copy in my build directory. I modified the current build script to copy those files into the package and the software then functioned normally.
VirtualBox was next on the poop list. I compiled version 6.1.34 only to be greeted with several issues. One bug is somehow some of the /usr/bin sym link commands no longer are created in lower case and only mixed case. I had to modify the build script to restore those lower case versions. There also was a run-time failure about failing to load some R0 module. I surrendered and built version 6.1.32. That version ran nicely.
Another speed bump was compiling conky. I prefer the pre-LUA version. Compiling failed but adding the -fcommon option resolved the failure.
Another failure was dvb-apps. This required time to find patches but eventually I was able to compile and the scan command functioned correctly.
Two more problematic packages were LIRC and my preferred version of XBMC. These packages are important for the living room media player.
Apparently respective LIRC modules no longer are provided with the kernel. That meant I had to compile a newer version. I was able to compile a new LIRC package but the newer version runs differently than the previous version. I had no idea how to configure and run the newer version of LIRC. I dislike reading gobs of documentation because basic functionality changes. Configuring LIRC is complex software and geek territory and not a calm walk on a sunny afternoon. Odd how one of the common Linux kernel developer mantras is “do not break user space” yet user space is broken quite often by such changes.
Try as I might my old version of XBMC failed to launch in Slackware 15.0. Perhaps I am living on borrowed time, but in 14.2 I was able to shoehorn the compiled 14.1 package with some sym link trickery. That voodoo magic probably remains okay, but the software fails to launch with the newer X server.
I suspect I will have to keep the media player locked to Slackware 14.2. One long hope is creating a Slackware 14.1 build system for compiling. Slackware 14.1 was the last release where I could compile XBMC 10.1. I will try to backport as many dependency packages as possible with newer versions from 15.0 and compile XBMC 10.1 in this Frankenstein environment. The hope is installing a 14.1 package in 15.0 then might not break. Even if I can backport most packages, I suspect the attempt will fail because the run-time failure in 15.0 was related to the X server rather than dependencies. Even if I succeed running XBMC 10.1 in 15.0 I still have to wrangle with the newer LIRC.
With a freshly compiled collection of third party packages I again tested my script to update a system from 14.2 to 15.0. By this time the script was refined and included installing the newly built third party packages. On my test VM the update completed in about 66 minutes. The T400 laptop with an SSD took about 108 minutes. On my testing partition on the office system the update required about 91 minutes. These times remain unsettling to a long time computer user.
I was hardly finished. The final grunt work began. All I had accomplished was proving I could update a system with little to no screaming. I needed to test desktop environments and new versions of software. I needed to test and revise shell scripts and review logs. This takes time. Weeks. This is the territory of death by a thousand paper cuts and where the proverbial rubber meets the road. After all, if I cannot use the updated environment then I have gained nothing.
Posted: Category: Usability Tagged: Slackware
Next: Slackware 15 — 3
Previous: Slackware 15 — 1