Bug#901437: Add footnote warning readers that sometimes shared libaries are not coinstallable
Package: debian-policy
Version: 4.1.4.2
Hello,
Filing a bug so this doesn't get lost.
On Sat, Jun 02 2018, Russ Allbery wrote:
> Adrian Bunk <bunk@debian.org> writes:
>> On Thu, May 31, 2018 at 12:37:00PM -0400, Marvin Renich wrote:
>
>>> libcurl4 conflicts with libcurl3, which violates the stated purpose of
>>> the "must" clause at Policy 8.1 (to allow multiple versions of a shared
>>> library to be co-installable), even though it doesn't violate the
>>> letter of the must (binary package name must change when SONAME
>>> changes). Without the second sentence at Policy 8.1, the MUST
>>> requirement serves no purpose, so I have given this severity serious.
>
>> Another purpose (not stated in the policy) is that software compiled
>> against the old SONAME cannot work with the new SONAME, and changing the
>> package name is the cleanest solution to express that through the
>> package dependencies.
>
>> In most cases parallel installation of several SONAME versions of a
>> library is a working setup, but for cases like libcurl3->libcurl4 the
>> only thing you could argue for would be changing the wording in policy -
>> parallel installation is not technically feasible here.
>
> Adrian is of course correct.
>
> The libcurl situation is exceptional and warranted a project-wide
> discussion looking for cleaner migration paths (to no avail), so I think
> it would cause more confusion than clarity to try to spell out the cases
> where this sort of action is warranted. But maybe a footnote is in order
> to warn the Policy reader that sometimes this happens. How about this?
>
> --- a/policy/ch-sharedlibs.rst
> +++ b/policy/ch-sharedlibs.rst
> @@ -63,13 +63,24 @@ The run-time shared library must be placed in a package whose name changes
> whenever the ``SONAME`` of the shared library changes. This allows several
> versions of the shared library to be installed at the same time, allowing
> installation of the new version of the shared library without immediately
> -breaking binaries that depend on the old version. Normally, the run-time
> -shared library and its ``SONAME`` symlink should be placed in a package
> -named libraryname\ *soversion*, where *soversion* is the version number in
> -the ``SONAME`` of the shared library. Alternatively, if it would be
> -confusing to directly append *soversion* to libraryname (if, for example,
> -libraryname itself ends in a number), you should use
> -libraryname-\ *soversion* instead. [#]_
> +breaking binaries that depend on the old version. [#]_
> +
> +.. [#] There are some exceptional situations in which co-installation of
> + two versions of a shared library is not safe, and the new shared
> + library package has to conflict with the previous shared library
> + package. This is never desirable, since it causes significant
> + disruption during upgrades and potentially breaks unpackaged
> + third-party binaries, but is sometimes unavoidable. These
> + situations are sufficiently rare that they usually warrant
> + project-wide discussion, and are complex enough that the rules for
> + them cannot be codified in Debian Policy.
> +
> +Normally, the run-time shared library and its ``SONAME`` symlink should be
> +placed in a package named libraryname\ *soversion*, where *soversion* is
> +the version number in the ``SONAME`` of the shared library.
> +Alternatively, if it would be confusing to directly append *soversion* to
> +libraryname (if, for example, libraryname itself ends in a number), you
> +should use libraryname-\ *soversion* instead. [#]_
>
> To determine the *soversion*, look at the ``SONAME`` of the library,
> stored in the ELF ``SONAME`` attribute. It is usually of the form
--
Sean Whitton
Reply to: