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@lists.fedoraproject.org/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