This is only for those who depend on Slackware ARM 14.2 HF - current, the only HardFloat ARM version ATM, are continuously updating the system with the automated slackpkg upgrade-all and looking to survive between the packages updates. Once every 3-4 months I get my ARM systems broken after a slackpkg update with some missing dependencies / removed packages (not upgraded, removed only, but available in the new packages section).

Please take note that Slackware ARM 14.2 HF - current is still BETA and drmozes policy and advice (apparently) is to reinstall Slackware ARM 14.2 HF - current on every update.

Here are the issues I've experienced and collected between the updates in my changelog:

--- March 2017
- apps/libs relying on the following libraries will get broken:
/usr/lib/libevent-2.0.so.5

--- June 2017
--- November/December 2017
- apps/libs relying on the following libraries will get broken:
/usr/lib/libva.so.1
/usr/lib/libva-drm.so.1
/usr/lib/libva-x11.so.1

There is no hardware floating point version of 14.2 and there never will be.

14.2 was the last version of the software floating point port, and you *cannot* perform an in-place upgrade from it to -current. You must reinstall. The upgrade documentation ('UPGRADE.TXT') in -current has stated this since early October.


I did not say this. I said that you should reinstall _your_ system.
Why are you doing this?

If you are building your own software that links to some of the newly upgraded packages, then you need to rebuild the self-built sofware, not make symlinks as you're doing. There's a reason why the major number has changed, and that is usually because the API changed between versions. Whilst making these symlinks may fix any dependencies that become broken between updates, the binary (or other library) that is linking, most likely will fail in some way because it's compiled to use the previous API structure. Most libraries only change major number when the API changes.

Also, it's very rare that either x86 or ARM Slackware is pushed out with Slackware packages that have broken libraries (we have a bunch of tools that do package integrity checks prior to making public a batch of updates), hence why I suggested reinstalling _your_ system. I regularly check to ensure that on a fresh system, all installed packages have no broken dependencies.

The survival guide is simple:
* Read the change log before doing _anything_.
* Remove old packages
* Install new packages
Usually (not not always) the change log contains information about how to upgrade to a package, or when a binary has moved from one to the other.
Where one package has been renamed to another (such as man-> man-db), in ARM I usually include how to upgrade directly from one to the other.
If migrating from one package name to another will break the system if you removepkg the previous one, the change log always explains the migration path (e.g. util-linux -> util-linux-ng). In those cases, if you let an automated tool do this for you, you're screwed.

Now, are you going to reinstall or not? ;-)

@drmozes
My goal was to have a thread dedicated on the development of the Slackware ARM 14.2 HF -current, check the the updates and provide some fixes for some packages that will get removed and not upgraded during an slackpkg upgrade-all process. All this for the ones who are continuously updating and not re-installing on every update Slackware ARM 14.2 HF -current. I had no intention to involve you in this as your goal and work/attention is to get the final Slackware ARM 15 HF ready.
Sorry for using Slackware ARM 14.2 HF -current instead of Slackware ARM HF -current, but the -current is based on 14.2 and still has this version available:
I never version-upgraded a Slackware System, but only backed up conf/work stuff and installed the new version clean/fresh. Usually that was also the occasion to upgrade HW/change HardDrives on production systems.

I'm doing the relinking on new lib packages in /usr/lib because there are some user-space depending software packages that have absolutely no reason to get recompiled on every package update and because with the updates, the compatibility with the old lib packages was removed. Simple, isn't it? It's the "conservativeness" quality, among others, that I do really appreciate with Slack.

Exactly that's why I started this thread and was considering to update when the official and automated slackpkg upgrade-all will "break" things, at least until Slackware ARM 15 HF will be released.

Nope!
I do have a few systems relying on the BETA Slackware ARM 14.2 HF -current (cut the version out if you like) and a re-install would be an overkill.

As suggested, I checked the changelog for Slackware ARM -current and found the hostname package update:
http://www.slackware.com/changelog/current.php?cpu=arm
"
a/hostname-3.18-arm-1.txz: Added.
This is the latest version of the hostname utility, broken out into a new
package to get rid of duplication between util-linux and net-tools.
"
I remember running slackpkg upgrade-all around 24-26-November and loosing /bin/hostname (reported in another thread). Is this a slackpkg internal issue? Or, if a package appears as "added" and not "upgraded" in the changelog, then slackpkg will simply remove the existing/installed one, as you said - "screw" the system and leave the user with a broken system that needs a "reinstall", as it was suggested?
I just hope that the cases reported in my original post (and the scope of this thread) are just some errors in the slackpkg update/upgrade process, otherwise I'll stop using slackpkg upgrade-all - and suggest to remove the upgrade-all target for good.

Yes this is confusing - perhaps I'll change it to "post_14.2" up until 15.0 is released.
What's worth bearing in mind is that people reading your threads may learn incorrect information, hence I like specificity - particularly when there's the ability for it to exist cogently.
It's "-current". There is only one of them and it has no version.

Same here. Tends to be lots of old files left around if you do an in-place upgrade.

Please continue to contribute your experiences to the community, but please don't advocate further suggestions (such as symlinking older library names to newer ones) when I have explained the technical reasons why not to: your contributions will be of more value if they technically well-grounded.
What also tends to happen is that inevitably _I_ do get involved because people email me about issues which I spend time looking at, only to find that someone followed incorrect advice.
I have explained briefly about major library numbers, and you can find many in depth articles about shared libraries and Linux on the web. If you look at the change log, you'll often see that packages were rebuilt against some library. This is because the library's API has changed, thus the packages linking to it need rebuilding.

Your logic puzzles me. If anything it's pre-(some months)-15.0.

As regarding slackpkg - I don't use it, never have apart from to test the epoch date-quit patch I made for it.
As you may have seen though, you're not the only one to have issues with it - there have always been a few posts every few months on x86 where someone has an issue when package names are changed, added and removed. Slackware is not made for automated package update tools. Generally it works well on stable releases though, but for -current, I wouldn't use it. I have no issues upgrading packages on my systems in -current, as I do it manually.

That should be posted in a sticky thread in the main Forum!

Brilliant summary, valid for all Slackware architectures!

@drmozes
Just added the missing update method specification for the target audience in my original post from:
This is only for those who depend on Slackware ARM 14.2 HF - current, the only HardFloat ARM version ATM, are continuously updating the system and looking to survive between the packages updates.
to:
This is only for those who depend on Slackware ARM 14.2 HF - current, the only HardFloat ARM version ATM, are continuously updating the system with the automated slackpkg upgrade-all and looking to survive between the packages updates.

I promise I'll never use Slackware ARM 14.2 - current again, but only Slackware ARM -current

I just changed the original post accordingly, removed the symlinks. I guess this workaround is a "defect" that I inherited from a very long time ago when I had systems where I did some updates offline (no internet). I did this symlinking substitute only for non-core libraries and always tested the functionality before considering it a stable fix. You're right, this shouldn't be done and all the technical details you provided are sound. I was not advocating anything but just presented a workaround, which I removed now.

Well, I do have some Raspberry Pi systems loaded with -current, the only HF Slackware ARM available, used in production environments (I know I shouldn't do that but have no alternative), that I cannot reinstall on every update issue. I'll stop updating them for sure. Besides, I'm a sort of a purist, I do install a Slackware ARM clean and not mess around with it, keep clean images and use them if the system gets somehow corrupted. On ARM, due to the fact that the system resides on SDCard and in order to protect it (extend its life) this images approach is the best I could come up with.

Thanks for confirming again that the automated package update tools can break the system, I wasn't aware of that and considered that only the BETA stage -current versions, the ones that are actively developed, can be affected, that's why I started this thread in the first place and it looks that it wasn't a bad idea after all as I can keep updating on the glitches I'll further experience. TBH, I never used any update tools on Slackware but manually compiled and updated some key components (kernel/network-routing/security related packages/provided services related packages (a few libs) that were needed for a service upgrade) until I got "hooked" with slackpkg under Slackware ARM -current.