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 <[email protected]> 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
