Bug#509933: versioning SONAMEs of shared libraries is not clearly recommended
Steve Langasek <vorlon@debian.org> writes:
> On Thu, Jul 08, 2010 at 10:10:51AM -0700, Russ Allbery wrote:
>> - <sect id="sharedlibs-runtime">
>> - <heading>Run-time shared libraries</heading>
>> + <p>
>> + A shared library must be uniquely identified by an <tt>SONAME</tt>
>> + attribute stored in its dynamic section.
> This wording is going to cause problems down the line.
> $ objdump -p /lib/libc.so.6 /lib/i686/cmov/libc.so.6 |grep SONAME
> SONAME libc.so.6
> SONAME libc.so.6
> $
> $ objdump -p /lib/libc.so.6 /lib32/libc.so.6 |grep SONAME
> SONAME libc.so.6
> SONAME libc.so.6
> $
> And multiarch further increases the frequency of non-unique SONAMEs on
> the system. So more explanation is needed of what 'unique' actually
> means here.
After further consideration, I don't think "uniquely" was really adding
anything here, so I just rephrased this to:
A shared library is identified by the <tt>SONAME</tt> attribute
stored in its dynamic section.
which I think still gets the basic point across.
>> + 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
> I would say "the shared library's full file name", as I consider the
> SONAME to *be* the name of the library :)
Changed.
> I would write this footnote as:
> This is a convention of shared library versioning, but not a requirement.
> Some libraries use the <tt>SONAME</tt> as the full library file name
> instead. Most, however, encode additional information about
> backwards-compatible revisions as a minor version number in the file
> name. The <tt>SONAME</tt> itself only changes when binaries linked with
> the earlier version of the shared library may no longer work, but the
> filename may change with each release of the library. See
> <ref id="sharedlibs-runtime"> for more information.
Thanks, this is much better. Applied with some tweaks.
>> + as a symlink pointing to the shared library.<footnote>
>> + Some shared libraries have no version information in
>> + their <tt>SONAME</tt> and therefore need no symlink since the
>> + file found when linking is the same as the library name. This
>> + is highly unusual, however, and means the shared library cannot
>> + be versioned. It is used only for very special situations where
>> + the shared library provides a tiny set of symbols and must not
>> + be versioned for some reason.
>> + </footnote>
> I don't think this footnote adds anything. Why document that it's
> possible to create shared libraries that don't follow policy?
There are shared libraries in Debian that don't have version information
in their name, but they're all really weird special cases that, for the
purposes of this section, probably aren't public shared libraries.
(libmemusage.so, for example.) So I think I concur and dropped the
footnote.
>> - <p>
>> - Since it is common place to install several versions of a
>> - package that just provides shared libraries, it is a
>> - good idea that the library package should not
>> - contain any extraneous non-versioned files, unless they
>> - happen to be in versioned directories.</p>
> I don't see anywhere else that this recommendation is retained in this
> patch. The existing wording is rough, but I think it needs to be
> pointed out that shared lib packages can't contain other files in
> unversioned paths without running into Breaks/Replaces pain.
This whole paragraph was just an inferior restatement of something that
was already stated much more clearly in the next section, so I just
deleted it since we're about to make a stronger and more complete
statement. See Policy 8.2.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: