Unix has it, Linux has it, Windows has it -- the ability to have multiple versions of libraries (like GLIBC) on a system with the ability to run programs from multiple MAJOR OS releases, on the same system. So why aren't we building our apps and libs to work that way in OpenSuse? Starting with the 12.X series, it seems the problem has gotten significantly worse. Binaries from each of the 12.x versions are often mutually incompatible -- most often because each version has been hard-coded to accept only 1 version of GLIBC. GLIBC isn't supposed to be changing it's interface so radically that each app needs to be hard coded to only work with 1 version. In versions prior to 12.x, requirements were put on the rpm's to make sure the unique version of Glibc an app wanted was 'installed'. That wasn't hard to work around, as one could install the markers in the rpm-database and glibc linked apps would run fine with the newest version of libc installed. Currently we have version 6 of the libc library libc.so.6. All of the 12.x series is linked to this file, BUT all have specified exact internal versions of each compatible version of libc.so.6 : GLIBC_2.14, GLIBC_2.15, GLIBC_2.16? Why are apps specifying internal symbols to link against? linux has a facility for linking to specific versions of libc.so.6: libc.so.6.2.14 can live with libc.so.6.2.15 and libc.so.6.2.16. All can be installed , if *NECESSARY* (which, in my experience usually isn't necessary until 'libc.so.7' comes out), and apps provably have a need for a specific minor version, can specify which minor version by filename. So why are we hardcoding specific libc.so.6 revisions into the binaries? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org