On Fri, Aug 07, 2020 at 02:54:18PM -0400, Stephen Smalley wrote: > As noted in https://github.com/SELinuxProject/selinux/issues/245, > symbol versioning in libsepol causes problems for LTO. libsepol and > libsemanage have a handful of versioned symbols due to incompatible > ABI changes made early in the CIL integration. However, as far as I > can tell, these symbols were only used by other components of the > selinux userspace, not externally. Should we stop supporting the old > versions going forward and simplify the maps? If so, does this truly > require bumping the .so version or can we omit that since there are no > external users? Thoughts? > AFAIK libsemanage is used by some 3rd parties. We've had requests to ship libsemanage-devel in RHEL-8 repositories in order customers build their applications. >From my packager POV I like symbol versioning - it helps to prevent some dependency issues in development branches, e.g. when libsemanage is built with new libsepol symbol but the new package doesn't require newer libsepol. rpm is able to solve that: $ rpm -q --requires libsemanage ... libselinux(x86-64) >= 3.1-2 libselinux.so.1()(64bit) libselinux.so.1(LIBSELINUX_1.0)(64bit) libsepol.so.1()(64bit) libsepol.so.1(LIBSEPOL_1.0)(64bit) libsepol.so.1(LIBSEPOL_1.1)(64bit) libsepol.so.1(LIBSEPOL_3.0)(64bit) ... $ rpm -q --provides libsemanage config(libsemanage) = 3.1-2.fc33 libsemanage = 3.1-2.fc33 libsemanage(x86-64) = 3.1-2.fc33 libsemanage.so.1()(64bit) libsemanage.so.1(LIBSEMANAGE_1.0)(64bit) libsemanage.so.1(LIBSEMANAGE_1.1)(64bit) LTO seems to cause problems to other projects as well https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/XMIQMN5KNAZUPX6O3LN6JJGTCZTP4B7J/ So I'd prefer if we try to do and use symbol versioning correctly, but it's not hard requirement from my side. Petr
Attachment:
signature.asc
Description: PGP signature
