I am on 14.1 and have compiled some software from SlackBuilds.org, say 14.2 or 15.0, whatever the name, a new update comes out that has a lot of changes with things (lets act as if its an actual Slackware release to make it more real world like). If I try to update my Slackware system to this new version, will my compiled software (which I used Slackbuilds from slackbuilds.org) break/stop working because of the changes or will they work fine? Do I have to wait for the maintainers of SlackBuilds.org to update all of their software for 14.2 (if that is the name)? I noticed SlackBuilds.org has a dropdown search for 13.37, 14.0, 14.1, etc.

Some may break, some will still continue to work
Ponce have a separate current tree if you want to see what changes need to be done for next Slackware release

1 members found this post helpful.

I will just second what willysr said. I've been running --Current for several years on various boxes. Occasionally, an update breaks a package. It's not frequent, but it does happen.

A recent major update to --Current broke LibreOffice and VLC (I use AlienBob's packages for them). As soon as AlienBob had compiled the new versions (in a commendably speedy fashion, I must add), I installed them and everything worked again. The only other major breakage I recall was gtkam; I didn't bother to reinstall that--just mount the SD card instead. Those are the only ones that have affected me directly since 13.37 was released.

So is my safest option to stay on 14.1 until all of the SlackBuilds on slackbuilds.org have been made compatible for 14.2 (assuming that is the name)? How would it even be compatible though? I would have to remove everything and re-install for 14.2 or could I simply use something like sboupgrade ?

If I wanted to be safe, I'd never come outside to play! I have used Slackware64-current since it was born. I also have had a few broken sbo packages along the way. Just recompile them, or fix a dependency or whatever. Where's the fun in waiting? Go for it.

1 members found this post helpful.

First, write down all the SBo stuff on your machine. Something like:

Then, clean your system of third-party stuff:

Upgrade it to the next Slackware version.

And then, rebuild your stuff.

You can easily make them work even if they don't. In a similar way how Slackware's solibs packages work.

Note the missing dependencies after upgrade and find the packages containing them (for example: grep libboost_atomic.so /var/log/packages/*). Download the appropriate package from Slackware(64) 14.1 (or 14.1 patches if exist any) and extract only *.so.* files (for example: libgnutls.so.28.20.2). Than make the appropriate symlinks if needed (for example: if the app requires libgnutls.so.28, you would symlink libgnutls.so.28.20.2 to libgnutls.so.28). After that, I suggest moving them in a new directory: /usr/lib64/oldlibs, /opt/lib64/slack-14.1, whatever... Just put the directory path in /etc/ld.so.conf and run su -c ldconfig everytime you add a new lib.

This works nice in most cases (although I had to recompile a package or two anyway).

It's better to recompile instead of playing with symlinks since you may forgot someday which symlink was made manually in the past

Altrius, to give you the reasoning behind all this, there are a bunch of libraries with Linux. Everything from libjpeg to liblastfm to libusb. Many programs rely on these libraries for various functions to work. Looking at these three libs, it's reasonable to assume software dealing with pictures would use libjpeg, software playing music might support Last.FM support through liblastfm, and programs that can use peripherals would use libusb. When these libraries change (usually updated with newer versions, although, sometimes replaced, and sometimes removed), sometimes this breaks compatibility with the programs that rely on it. When that happens, you can typically just recompile the program and it will utilize the newer library.

So, when Slackware releases the next stable version, many of those libraries will have been updated from 14.1. In our three examples, going from 14.1 to -current, libjpeg has switched to libjpeg-turbo, liblastfm upgraded from 1.0.7 to 1.0.9, and libusb upgraded from 1.0.9 to 1.0.19. So, with these three libraries being updated, it stands to reason that compatibility with some of the programs relying on them might be broken, however, it isn't guaranteed that a version change breaks compatibility (in fact, many libraries try to keep compatibility, but sometimes the programs relying on them aren't designed to properly utilize newer versions without being recompiled).

So, long story short, it's possible that all your software you compiled will work fine, and it's also possible that none of it will. Most of the time, it's somewhere in the middle. Some programs will break, others will work fine. There's several different options provided to you in this thread, namely, you can keep everything and if something is broken after the upgrade, you can just recompile it, or you can just recompile all your programs before you run into problems. Personally, I would go the second route. It makes sure that a program you need will work properly when you need it, instead of trying to open a program only to find out you need to recompile it. kikinovak gave some great advice to save all the package names that you've built from SBo and then remove all those packages. Afterward, you could then just use something like sbopkg's sqg to generate the queue files for those programs and then just have everything build overnight. When you wake up, your computer should be back to normal.

As for SBo itself, the maintainers of the site have been keeping up to date with -current and almost all of the slackbuilds are ready for the next version of Slackware. Once Pat releases the next version, I'd imagine SBo will have that option in their dropdown within a day.

2 members found this post helpful.

Well, generally speaking that seems me rather optimistic. If I I remember well it takes a few weeks to have all SBo packages updated after a Slackware release.

What? Never did hear this before. The fun in waiting is that I dont want to have to deal with things breaking as much as possible, this is supposed to be a stable system you know?

For me that is fine, I would prefer waiting and don't mind waiting as 14.1 will still be supported and then waiting a few weeks or even a month or however long it will be for Slackbuilds to get everything working for 14.2 is fine really.

I think you misread what I wrote. There's no any playing with symlinks.

TLDR version: you make a directory outside of systems lib dirs like /opt/lib64/oldlibs and put the old libs inside. Than put it in ld.so.conf.

Only symlinks you make is those in /opt/lib64/oldlibs. You don't really mess up anything on your default install.

Cheers.

Yeah, we need to check EVERY packages in SBo and that takes some time. We often bump to the latest version without checking whether other apps depends on this package can build find or not.

In short, we want a smooth transition so it does take time to make that happen

I'll be honest, I haven't followed the development process in past versions as closely and consistantly as I have with this one. But it seems that ponce, willysr, 55020, and others are well on top of keeping ponce's unofficial SBo repo up-to-date. I remember reading that only a handful of SlackBuilds don't compile on -current and that fixes were being researched. It seems that it is pretty much ready to move over once Pat throws the switch, but we know there's still some more time for them to test and patch, since we haven't even gotten an RC version of Slackware yet.

I guess once the final version is released, they may go through and recompile everything based on the finalized install, but I don't know their process in getting everything prepped and pushed out when a new version is released.