This is another example of a snapshot that will make package
upgrades impossible w/o a full rebuild -- for a similar reason
rpm 4.15 can't be built by rpm 4.14 or before. rpm 4.11 ships
with rpmlibs-v3, while rpm4.15 ships rpmlibs-v9. The libs
jumped 6 versions while rpm went up 0.14.
The windows of what binaries work with what date of TW
is too small.
Is suse supporting this model for enterprise customers? I can't
believe they would tolerate it.
It used to be (before all binaries had version numbers included
in their binary), that you could upgrade across versions for
most things, or install multiple versions of some libraries
for various programs.
Glibc seems to support only a buggy API such that multiple versions
can't be used on the same machine as linked by file-name.
While some may think I have uniq problems, the intra-distro binaries
are going to have more and more of these cases. It's not a workable
situation.
I can take programs in Win from 10-20 years ago and they still work
on a current day win because the OS loads library updates by version.
Unix did the same -- but move to linux, and vendors got lazy and stopped
using the correct versions to link with.
Why? And how can this be fixed?