The recent update in slackware-current of the icu4c and boost packages caused some 3rd-party package breakage. The new versions of icu4c and boost come with incompatible library ABI changes.
Let me first elaborate a bit on the strategies that are available to a Slackware user on how to deal with incompatible library updates in -current.
One of the reasons people are wary of installing and running Slackware-current is the fact that at any given moment, distro updates can break 3rd-party packages (i.e. packages you have installed that are not part of the Slackware distribution itself). Slackware-current is in constant flux, it is our development environment, and software versions can make sudden jumps with unexpected consequences.
Big tip: before running any update on a slackware-current system, first check the ChangeLog.txt and scan the updates since your previous upgrade for the text “Shared library .so-version bump.” which is another way of saying “incompatible ABI change”.
If this text accompanies a package update you can be pretty certain that some 3rd-party packages that depend on it will stop working. And if that particular package is boost, icu4c or poppler, expect massive breakage. The safest approach in a case like this, is: wait with upgrading your Slackware-current; check for packages that have a dependency on the package with the ABI breakage: and track the 3rd-party repositories for updates that address the ABI breakage.
There is another strategy- one which allows you to upgrade to the latest -current while avoiding broken packages. That is to keep the older libraries on your system – the libraries your 3rd-party packages are depending on. You can simply extract these older libraries from the previous version(s) of the upgraded Slackware package. Darren Austen and I worked together to create a package repository containing historical Slackware-current packages (32bit, 64bit official packages and my own multilib archive). See https://slackware.uk/cumulative/ if you are in need of older package versions.
And in the special case of incompatible icu4c, boost and poppler updates, the easiest (short-term) workaround is to install my icu4c-compat, boost-compat and poppler-compat packages. Essentially, these convenience packages wrap the libraries of several older (original Slackware) icu4c, boost and poppler packages.
Applications that depend on these older libraries will keep on running and in the meantime you can wait for the 3rd-party packager to recompile the affected packages (or recompile yourself at your leisure). I update these packages immediately after updates to their Slackware originals. The process takes almost no time, compared with recompiling all the broken stuff.
NOTE: These ‘compat’ packages do not replace Slackware’s own icu4c, boost and poppler packages! They should be installed in parallel.
Libreoffice
The most obvious package breakage in my own repository is of course LibreOffice. It is a big package and many people do not want to recompile this themselves. A good decision, because the LibreOffice package would not compile against the new icu4c 65.1 and I needed to find the cause and create a patch first.
Since I had to compile new packages anyway, I went for the latest 6.3.2 release of LibreOffice which was announced two weeks ago.
Note that the new packages for LibreOffice 6.3.2 in my repository, do contain “libreoffice-kde-integration”, containing Qt5 and KDE5 (aka Plasma5) support.
If you do not have KDE5 packages installed at all, don’t worry. LibreOffice will work great – the KDE integration package just will not add anything useful for you. On the other hand, if you have Plasma5 installed you will benefit from native file selection dialog windows and other integration features. And even if you do not have Plasma5 but you do have Qt5 installed, then you will be able to run LibreOffice with Qt5 User Interface elements instead of defaulting to GTK3.
If you want to compile Libreoffice 6.3.2 packages yourself using my SlackBuild, then be aware that by default the KDE5 support is disabled. You will have to set the value of the script parameter “ADD_KDE5” to “YES”. Additionally you will have to install the packages that this functionality depends on otherwise the compilation will fail.
Read the ‘README.kde5‘ file in the source directory for the list of packages you’ll need. All of them can be found in my ‘ktown’ repository: https://slackware.nl/alien-kde/current/latest/
Enjoy! Eric
Which repo is poppler-compat in?
“slackpkg search poppler” doesn’t find it in my currently selected repositories.
Hmmm seems I created poppler-compat only for my own enjoyment. I have not added it to the public repository. Yet.
Cool, thanks! I don’t think I’ve come across any real troubles running current on the new box. I’ve had to recompile a couple things, but no real show-stoppers, unless you count frescobaldi. I think that one’s just too old for current. Once the next version of Slackware comes out and there’s a way to install PyQT5, I might look at building frescobaldi 3. But the lack of vi bindings is kind of annoying for any benefit I might get. (lilypond command line always works fine, as does xpdf and VLC for MIDI.)
Thank you Eric. These packages are a lifesaver indeed. And libreoffice installed OK without problems. Thanks again!
Great work Eric! Thank you for your work on Slackware!
Actually PV added the “old” icu4c libraries to aaa_elflibs:
Mon Oct 7 04:41:29 UTC 2019
a/aaa_elflibs-15.0-x86_64-12.txz: Rebuilt.
…
Added temporarily until third party packages have been recompiled:
libicudata.so.64.2, libicui18n.so.64.2, libicuio.so.64.2, libicutest.so.64.2, libicutu.so.64.2, libicuuc.so.64.2.
This is not as overarching as your *-compat packages (how does he know whether all 3rd party packages have been rebuilt), but will be enough for many (most?) people.
Looks like some relief for you.
😀
Yes, PV has done that before, so with Eric’s -compat packages you’ll get both belt and braces. However, with the next aaa_elflibs upgrade those temporary additions are generally removed while Eric’s packages are failsafe – I’m extremely grateful for those invaluable additions to his repo.
Your contribution tu Slackware community is uncompareable.
Thank tuo really mich!
Thanks Eric for providing tips on how to manage 3rd-party softwares with -current. I’m glad that my own approach is similar to your first strategy 🙂
I didn’t know about the cumulative repository. Did you advertise it in your blog? I don’t remember so. It’s a great initiative. It could come in handy in case one would like to roll back an upgrade. It may even make me more adventurous by switching my main machine to -current (from 14.2) earlier than waiting for first RC version in -current.
The need for historical packages from Slackware-current pops up from time to time, and at some point it was also discussed in Freenode IRC’s ##slackware channel.
I have a private archive of all the 64bit packages and all multilib gcc/glibc packages since release of Slackware64 and Darren Austen and I decided during that IRC discussion to use my archive to setup a public copy on Darren’s server (slackware.uk) and keep that cumulative archive updated daily through a cron job.
Darren started a fresh cumulative archive of 32bit packages too, from that moment on.
It was then announced on LQ, see https://www.linuxquestions.org/questions/slackware-14/cumulative-archive-of-slackware%7B-64%7D-current-and-multilib-trees-4175656996/
Hi Eric,
After checking ChangeLog.txt, I am impacted by icu4c, boost and poppler updates. I want to make sure I understand ok the procedure as a slackware -current newcomer.
1. slackpkg upgrade-all as usuall for all packages.
2. Install old icu4c-compat, boost-compat and poppler-compat packages from https://slackware.uk/cumulative/slackware64-current/. Do I have to add this repo to slackpkg+ repos? and install them.. I am not sure about this specific step.
Please clarify Eric. Thanks in advance and thanks for keeping _current in good (fitness) shape. 🙂
Hi Francisco,
No, icu4c-compat, boost-compat and poppler-compat are in Eric’s alienbob repo.
If you have that repo configured in slackpkg+ just install them normally.
Cheer,
I have updated the main article with direct links to the three compat packages in my own repository. As Ricardo already explained, these are not part of Slackware itself. If they would have been, then this would not have been an issue at all. The issue here is that the continuous evolution of the Slackware distro causes libraries to get removed which will break other non-Slackware binaries that depend on their presence.
Hence my compat packages in which I put libraries from older Slackware packages to help those people that run old or outdated programs.
Thanks Eric and Ricardo for your clarifications…
I Installed compatible packages from Eric repository. All is normal.
Thanks again for your explanation and for helping me in my slackware learning curve.
Regards, Francisco
Thanks for the history behind the cumulative repository.
I didn’t read the LQ thread (I’m not closely monitoring all LQ threads).
Hi Eric,
yesterday’s -current upgrades included a libdvdread upgrade which, I guess, will affect a number of 3rd party programs (even if PV temporarily kept libdvdread.so.4.2.0 in aaa_elflibs).
Will the .so bump affect your vlc and handbrake packages? Maybe not, since I can see that the sources in your build folders include older libdvdread versions (handbrake=6.00, vlc=6.0.1). Or would it be a good idea to follow your advice above and extract libdvdread.so.4.2.0 from the earlier package and keep it installed in /usr/lib64?
No doubt you’ll upgrade your vlc and handbrake packages in due course, but I understood from a posting of yours at LQ that you cannot find the time right now for recompiling big packages.
Exactly *because* Pat added libdvdread.so.4.2.0 to aaa_elflibs, no 3rd-party packages are affected.
But he removed the older icu4c libraries from aaa_elflibs which means you’ll have to have my icu4c-compat package installed if you want to avoid breakage in Plasma5.
The only external dependency on libdvdread.so.4 in my packages is in k3b by the way.
Thanks! Pat recompiled k3b for -current, so that should be OK (I haven’ taken the leap to Plasma5 yet so I use his kde4 version).
AFAIK none of my own SBo builds of 3rd party packages depend on libdvdread, but I’ll find out with the next aaa_elflibs update and rebuild if necessary.
Thanks for this very helpful Blog post, Eric!
Thank you Eric. Boost-compat package is a life-saver! And your explanation about the library-bump situation is indispensable for Slackware -Currenr users!
Wish you well and keep safe.