From The Linux Foundation
A number of LSB-specified libraries have seen substantial updates since going into LSB. The question is, does LSB need to follow this progression or not. This is a question that needs to be asked with every major LSB release.
- New functionality is picked up rapidly by at least certain applications, so there's incentive.
- Cannot move ahead of the curve: all distros that are certification targets should be able to implement the required functionality of a library without being forced to uplift their own versions.
- Have to make sure compatibility is maintained for older LSB apps.
- Use the Navigator for initial data surveys.
There are several cases:
- Symbol versioned library keeps soname but updates some symbols, leaving others the same and keeps older symbol versions of those that got new ones around. This is what the glibc family does. This approach should solve the compatibility question.
- Library bumps the soname. LSB would need to require both the old and the new library. Presumably distros would need to be supplying those anyway, so LSB requirements would not be an extra burden.
- Non-symbol-versioned library does not bump soname. In this case you hope all the changes have been made compatibly, but this is the case that has to be treated with most care.
Candidates for Uplift
Listed for discussion; we really only want to uplift a library when there's key missing functionality that apps are depending on.
- glibc - talked about in NewGlibc. Needed for the 128-bit long double support for four LSB architectures, inotify, and the stack-protector interfaces.
- GTK+ Stack. Printing needs support for 2.10, but we can't lift that far.
- X11 libraries. Not sure if there's new ABI material here.
- OpenGL. A newer ABI is definitely needed.
Smaller changes exist in many other libraries. Coming to mind are alsa, which was held back at 3.2 because of the support level of LSB 3-conforming systems. The Qt 4 specification was similarly held back.
libpam is now versioned, our's isn't, so this implies a possible uplift bug 1133. The same is true for libpng bug 1435.
Reimports
As a related topic, there are libraries that are not completely represented in the LSB specdb. These include the old LSB-Graphics module - X11 libs and OpenGL as well as any C++ library. The former we have good enough data for to generate stub libraries and checkers, but the headers are not necessarily correct. Since a form of the headers is used in the spec, this means there may be spec issues.
Reimporting implies refreshing the representation of the library without changing the base version, while changing the base version (uplifiting) probably also involves a "re-import" so these are related.
This is more complicated for C++ libraries (Qt 4, libstdc++). Tool work is needed completing an import of a library that's already partially in the database may not be as well handled as importing a fresh library. libtodb2 is in progress and seems like it will be able to do this job