Been thinking LSB 4.0 gives a dynamic linker independance there are a few uses to this.

Printer-friendly versionLike with sane and dbus not making it into LSB 4.0. If both projects could be asked to provide LSB 4.0 packages as runtime replacements for those apis and the dynamic linker be setup to pick those packages up. This ended the head ache of having to have all distributions on the same page. We decide that we want dbus 1.0 so we have dbus 1.0 and so on. Where there distributions catch up applications using LSB just drop the need to install runtime replacements. Very much like windows applications are now. At first they ship with extra bits until those extra bits become part of the OS. Yes we do need a common update system. Even over the longer term we could reduce the numbers of packages distrobutions need to build. There is really no need for the 1000+ copies of openoffice built all it equals is end users end up with out of date versions. A full LSB runtime constructed threw some means has to be considered. I would consider deals with each of the project makers like cups to provide the cups standard lsb package and so on. Full LSB runtime is really key to LSB complete coverage of the Linux world. Question really is if you build a full runtime how far back could we truly support. Linux's using kernels in the 2.6 and 2.4 serries or would it go even back more. Full runtimes many allow us that LSB 4.0 never has to die since its applications have there own dyanmic loader linked in. Basically lets declare distribution independence and start setting a benchmark for distrobutions to get to. Instead of distrobutions setting our limits. Peter Dolding