First of all, TOFU is generally frowned upon as a posting style on technical mailing lists. Second, IANADD and TINASOTODP; I speak only for myself. On Tuesday 01 September 2009 08:55:45 Joe Smith wrote: > We're making a set of interface libraries for use in cross-platform > application development. We want to 100% guarantee that if an application > is compiled against a particular version of the library, then it's > guarateed to work indefinitely with the same level of functionality. I think this is an unreasonable goal. That said, even if it is to remain the goal it should be implemented through disciplined library development and a thorough test suite, not through the linker. You *should* use the linker to retain backward compatibility (symbol versioning) and you *should* use other technical means to detect ABI changes before a release. > As > such, we can't upgrade the libraries underneath or we risk regression. This is misguided. If there is a security issue in the library, it needs to be able to be fixed in one place without recompiling all the programs that use the library. > Plus > this way we can break binary compatibility without issue between versions. While I guess it makes the library user happy, it will not make the application developers or packagers happy. Also, having so many versions that appear incompatible to the linker when they are actually compatible defeats the purpose of shared libraries; applications are much less likely to share them. This increases both RAM and HD usage needlessly. The increased RAM usage can also cause longer run times indirectly as there are more cache misses. > The other problem is that applications built against different versions can > be installed at the same time, and thus different versions of the actual > libraries themselves must also be installed at the same time. For this, I > don't see how we can get around it with a single package name. You might be able to have a single source package, but most likely you will need a different source package for each version. > The other option is to forget packaging altogether for the libraries and > package them with each application instead, but it would be more work for > the application developer to deal with that. It would also be more work for the security team. You might be able to use static linking, but that's generally frowned upon on Debian. Shipping the library along-side the application is also generally frowned upon. -- Boyd Stephen Smith Jr. ,= ,-_-. =. email@example.com ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Description: This is a digitally signed message part.