The End Of The Road
I expected this day to arrive.
For years I have been using XBMC 10.1 in the living room media player, going back to when the system was a full-scale Home Theater PC (HTPC). To date I have been able to compile version 10.1. As I move toward updating my systems to Slackware 14.2, XBMC 10.1 is the only package I cannot compile.
I am no compiling wizard. I am not a C programmer. Try as I might, I am unable to patch the compiling failures.
Why insist on the older app?
Many people believe apps should be updated with the “latest and greatest” release. That new and shiny is always better. While more often than not newer releases are improved, I do not embrace the belief that updating is “the greatest.”
XBMC versions after 10.1 require users to use a database to access videos. I use a simple and well-planned directory/folder structure to store videos. This layout works well with the 10.1 version. No database or library needed.
Newer XBMC/Kodi versions are developed with a presumption of 24/7 online connectivity. While I am guessing much of that connectivity is easy to disable, I dislike this presumption. I do not want any software phoning home. For any reason. Not even to check for updates. If I want to update plugins or movie data I will do so manually.
Even with version 10.1, to prevent the app from continually phoning home, I configured the built-in proxy to a non existing port. I don’t know whether that is possible with newer versions of Kodi.
All I want is a nice interface that works well with an infra red remote control. XBMC has been a great interface to the DVD collection. That is all that is wanted. None of the remaining bling is needed or wanted. Not even weather apps.
What are my choices?
I can forever keep using XBMC 10.1 on Slackware 14.1. This is doable. The computer is treated as an appliance anyway. Slackware 14.1 does not reach end-of-life until at least October 2018. Older Slackware releases are being supported longer than 5 years. Perhaps 14.1 will be treated likewise with security updates.
I can install Kodi and start the process of weeping and gnashing of teeth. Learn how to disable the cruft. Learn how to migrate the old data to a newer version. If possible.
I can find a different interface to watch videos.
There is one more potential option. A hack.
In Slackware 14.2 I installed the XBMC 10.1 package compiled for Slackware 14.1. From a terminal I tried to run XBMC. By following the output I was able to resolve run-time errors.
I copied a single file from the Slackware 14.1 libcdio package:
Then I created symlinks required by XBMC:
(cd /usr/lib64; ln -s libcdio.so.13.0.0 libcdio.so.13) (cd /usr/lib64; ln -s libicule.so.56.1 libicule.so.51) (cd /usr/lib64; ln -s libicuuc.so.56.1 libicuuc.so.51) (cd /usr/lib64; ln -s libicudata.so.56.1 libicudata.so.51) (cd /usr/lib64; ln -s libGLEW.so.1.13.0 libGLEW.so.1.9)
XBMC 10.1 then ran on Slackware 14.2.
There was a caveat with this hack. Slackware 14.2 uses pulseaudio. Previous Slackware releases did not. The version of XBMC compiled for 14.1 was not compiled with pulseaudio support.
In Slackware 14.1 I compiled and installed the speex, json-c, and pulseuadio sources from Slackware 14.2. Then I recompiled XBMC 10.1.
After creating the new package I deleted the pulseaudio package from 14.1. In 14.2 I installed the newer XBMC package.
All worked as expected.
Another option might be to compile XBMC 14.1 as a static build rather than use dynamic linking. I have no experience with this.
Herein lies one of the bitter sweet aspects of free/libre software. Broken software. The motto is simple — update the package or go away. Often, backwards compatibility is not supported. Users are expected to roll over and wet themselves with new features when all they want is the simplicity of the older software. Developers don’t care. Software development is their personal playground. In this respect they play the role of bully quite well.
Conversely, free/libre software allows me the freedom to tinker.
I got lucky.
I am disappointed. A tad bitter. Yet relieved.