John Fischer writes: > LCMS [Little CMS] [1] is a Color Management System implementing > the International Color Consortium's ICC.1:2004-10 Specification. > [2]
The last CMS we had was removed with force due to security problems ... just a sanity check: this new CMS doesn't share any of the design problems with the previous one, right? > /usr/lib/liblcms.so.1.0.16 How does the upstream handle versioning? If it's integrated like this, then applications linked against "-llcms" will break when we do an upgrade to version 1.0.17, because they'll all have the old object name. This will end up requiring us to keep around multiple library versions, and that will put us at very high risk of having applications that end up with multiple incompatible libraries loaded into their address space due to libraries that link with libraries. If the upstream is normal, then the first digit represents the major version, which may be incompatible. The second represents minor, which is just new features, and not incompatible. And the last is the patch, which is just bug fixes. Does it work like that? If so, then this should just be liblcms.so.1. > By default, LCMS installs its header files under /usr/include. > We propose changing this default installation location to a more > suitable /usr/include/lcms, for the purpose of avoiding namespace > pollution in /usr/include. How annoying will that be for applications? Do the applications that use this library all rely on "-I" information from pkgconfg, or do some assume that the default location is the right one? > LCMS's development and release schedules are controlled by > a group of developers external to SMI. [1] Although LCMS > attempts to maintain API and ABI compatibility between Major > releases, no explicit guarantee of compatibility is provided > by the LCMS developers. If we're going to have things depending on this, would it be worthwhile to have _Sun_ provide that guarantee? Otherwise, lower stability may well lead to a mass of hard-to-maintain contracts. What matters most here are *intent* and *track record*. Software is produced by humans, and nobody can ever make certain that mistakes are never made. Instead, our compatibility guarantee is that if we do manage to break something, we'll fix it. Thus, it makes sense that these external developers can't "guarantee" anything, because they're not going to deliver patches to Sun customers. If the upstream's intent is to keep ABI compatibility (even across major releases), then this sounds like Committed to me, not Uncommitted. We're not doing anyone a favor by getting cold feet merely based on the source of the code. > /usr/bin/icctrans Uncommitted Executable Location How would the binary location change over time ... ? > /usr/lib/liblcms.so.1.0.16 Uncommitted Shared Library > /usr/lib/liblcms.so.1 Uncommitted Symbolic Link > /usr/lib/liblcms.so Uncommitted Symbolic Link I don't think that intermediate symbolic link does anything useful. The linker only records the actual file name (liblcms.so.1.0.16), and only uses the ".so" link to find it, so that liblcms.so.1 just provides obfuscation. ;-} > /usr/lib/pkgconfig/lcms.pc Uncommitted Pkg-config Entry This actually looks Project Private to me. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
