Bug#901437: marked as done (Add footnote warning readers that sometimes shared libaries are not coinstallable)
Your message dated Sun, 02 Sep 2018 20:49:29 +0000
with message-id <E1fwZJJ-0009iQ-Oo@fasolo.debian.org>
and subject line Bug#901437: fixed in debian-policy 188.8.131.52
has caused the Debian Bug report #901437,
regarding Add footnote warning readers that sometimes shared libaries are not coinstallable
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact email@example.com
Debian Bug Tracking System
Contact firstname.lastname@example.org with problems
--- Begin Message ---
- To: email@example.com
- Subject: Add footnote warning readers that sometimes shared libaries are not coinstallable
- From: Sean Whitton <firstname.lastname@example.org>
- Date: Wed, 13 Jun 2018 11:39:25 +0100
- Message-id: <email@example.com>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <20180602201440.GA8777@localhost> <firstname.lastname@example.org>
Filing a bug so this doesn't get lost.
On Sat, Jun 02 2018, Russ Allbery wrote:
> Adrian Bunk <email@example.com> 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
--- End Message ---
--- Begin Message ---
We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to firstname.lastname@example.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
Sean Whitton <email@example.com> (supplier of updated debian-policy package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing firstname.lastname@example.org)
-----BEGIN PGP SIGNED MESSAGE-----
Date: Sun, 02 Sep 2018 13:27:09 -0700
Binary: debian-policy debian-policy-ja
Maintainer: Debian Policy Editors <email@example.com>
Changed-By: Sean Whitton <firstname.lastname@example.org>
debian-policy - Debian Policy Manual and related documents
debian-policy-ja - Debian Policy Manual and related documents (Japanese)
debian-policy (184.108.40.206) unstable; urgency=medium
[ Sean Whitton ]
* Drop stray colon in 4.9.
Thanks to Thorsten Glaser for pointing this out.
* New "Seeking seconds for a patch" section in README.md.
Ralf Treinen suggested recommending that those who propose patches
include word diffs and/or side-by-side diffs.
* README.md: remove a lot of outdated information, some wordsmithing,
and rearrangement to highlight opportunities for contribution.
[ Russ Allbery ]
* Add a footnote warning that different SONAMEs of the same shared
library cannot always be made safely co-installable, but these
exceptions are complex and beyond what Policy can explain.
343160f6427076cfd55a1a399999d14b3bea6024 2019 debian-policy_220.127.116.11.dsc
f1111872681e7e3f3c6ec8665b5eb9e403748c13 526824 debian-policy_18.104.22.168.tar.xz
8f94fce2fc5186c6cf8355763b5a810ec0f6802378b48db95a609c9f9cb5c9af 2019 debian-policy_22.214.171.124.dsc
b8830ba610988f0423862e4e38d95d16a30c658ce006e67f5fdc03f54d300f7b 526824 debian-policy_126.96.36.199.tar.xz
c092115cf690cbc7c6aab629aecbd941 2019 doc optional debian-policy_188.8.131.52.dsc
cbdb7ec849b412ec432e390780a4a0d2 526824 doc optional debian-policy_184.108.40.206.tar.xz
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
--- End Message ---