On Thu, 08 Jul 2010, Russ Allbery wrote: > Objections, sections, or other review?
Looks mostly good, I have some fixes and suggestions below. > - <sect id="sharedlibs-runtime"> > - <heading>Run-time shared libraries</heading> > + <p> > + A shared library must be uniquely identified by an <tt>SONAME</tt> s/an/a/ ? (I saw it several times, sounds odd to me but maybe I miss something) > + attribute stored in its dynamic section. When a binary is linked > + against a shared library, the <tt>SONAME</tt> of the shared > + library is recorded in the binary's <tt>NEEDED</tt> section so > + that the dynamic linker knows that library must be loaded at > + runtime. The full name of the shared library (which usually > + contains additional version information not needed in > + the <tt>SONAME</tt> is therefore not referenced directly. Missing ")" after SONAME. > + Instead, the shared library is loaded by its <tt>SONAME</tt>, > + which exists on the file system as a symlink pointing to the full > + name of the shared library.<footnote> > + Some unusual libraries have an <tt>SONAME</tt> which matches the > + full library name, but normally there is a minor revision that > + changes even though the ABI has not changed in a > + backward-incompatible way. The <tt>SONAME</tt> only changes > + when binaries linked with the earlier version of the shared > + library may no longer work. See <ref id="sharedlibs-runtime"> > + for more information. > + </footnote> > + This symlink is updated and its location cached > + by <prgn>ldconfig</prgn>, but must also be created by the > + package. <ref id="sharedlibs-runtime"> describes how to do this. I'm not sure the ldconfig bit is relevant here. Simply state that the symlink must be provided by the package (created is confusing, it might mean created by the postinst through the ldconfig call). If you want to speak of ldconfig you can put it in a footnote saying that the symlink might be updated by ldconfig and that the real location is cached to optimize the work of the dynamic loader ld.so. [...] > + The <tt>SONAME</tt> and binary package name need not, and indeed > + normally should not, change if new interfaces are added but none > + are removed or changed, since this will not break binaries > + linked against the old shared library. Correct versioning of > + dependencies on the newer shared library by binaries that use > + the new interfaces is handled via > + the <qref id="sharedlibs-shlibdeps"><tt>shilbs</tt> > + system</qref>. s/shilbs/shlibs/ and you might want to state "shlibs or symbols" Cheers, -- Raphaël Hertzog Follow the Debian Revolution ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100709070004.ga2...@rivendell
