Changeset 5e7593e

Timestamp:

06/04/2023 11:31:59 AM (4 months ago)

Author:

Xi Ruoyao <xry111@…>

Branches:

12.0, 12.0-rc1, multilib, renodr/libudev-from-systemd, trunk, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/loongarch, xry111/loongarch-12.0, xry111/parallelism

Children:

0f18f2b, 5e61857

Parents:

d4a32f9

Message:

pkgmgmt: Revert some of reword for "dependency hell" from Bruce

Use "library name" (instead of "library version") for SONAME (for now).
And "conflicting locations" may not be a problem if the symbol is at two
locations but they are exactly same (or ABI compatible).

For the details see lfs-dev discussion.

The current word is still not perfect (we've not defined "the name of a
shared library" at all), so I guess we'll need to make a major revision
for the entire "upgrading issue with shared libraries" thing in the
future.

File:

• chapter08/pkgmgt.xml (modified) (1 diff)

chapter08/pkgmgt.xml

@@ -87 +87 @@
 
       <listitem><para>If a package is (directly or indirectly) linked to both
-      the old and new versions of a shared library (for example, the package
+      the old and new names of a shared library (for example, the package
       links to both <filename class='libraryfile'>libfoo.so.2</filename> and
       <filename class='libraryfile'>libbar.so.1</filename>, while the latter
       links to <filename class='libraryfile'>libfoo.so.3</filename>), the
       package may malfunction because the different revisions of the shared
-      library present conflicting locations for some symbol names. This can be
+      library present incompatible definitions for some symbol names. This can be
       caused by recompiling some, but not all, of the packages linked to the
       old shared library after the package providing the shared library is