Adrian Bunk <b...@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 -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
