On Wed, Sep 30, 2020 at 11:56 AM Petr Lautrbach <plautrba@xxxxxxxxxx> wrote: > > On Wed, Sep 30, 2020 at 11:22:21AM -0400, Stephen Smalley wrote: > > On Wed, Sep 30, 2020 at 10:51 AM Petr Lautrbach <plautrba@xxxxxxxxxx> wrote: > > > > > > It's due to the previous ABI incompatible change > > > > > > Signed-off-by: Petr Lautrbach <plautrba@xxxxxxxxxx> > > > > My only real question is what are the implications for distros for > > this change? Would Fedora end up having to carry both so versions for > > a time? Or can you cleanly switch from the old to the new without > > disruption? > > > > Fedora and other distribution will need to temporary ship something like libsepol-compat and > libsemanage-compat with libsepol.so.1 resp libsemanage.so.1 in order not to > break buildroots. Also all packages which require so.1, see bellow, will have to > be rebuilt against so.2 > > # dnf repoquery --whatrequires libsepol.'so.1()(64bit)' > libselinux-utils-0:3.1-3.fc34.x86_64 > libsemanage-0:3.1-2.fc33.x86_64 > libsepol-devel-0:3.1-3.fc33.x86_64 > parted-0:3.3-6.fc34.x86_64 > policycoreutils-0:3.1-4.fc33.x86_64 > python3-setools-0:4.3.0-5.fc33.x86_64 > secilc-0:3.1-2.fc33.x86_64 > > # dnf -C repoquery --whatrequires 'libsemanage.so.1()(64bit)' > libsemanage-devel-0:3.1-2.fc33.x86_64 > policycoreutils-0:3.1-4.fc33.x86_64 > python3-libsemanage-0:3.1-2.fc33.x86_64 > shadow-utils-2:4.8.1-4.fc33.x86_64 > sssd-common-0:2.3.1-4.fc33.x86_64 > sssd-ipa-0:2.3.1-4.fc33.x86_64 > > I've experienced with this, builds are available in > https://copr.fedorainfracloud.org/coprs/plautrba/selinux-fedora/ > > E.g. for libsemanage, I've added > > +%set_build_flags > +CFLAGS="$CFLAGS -fno-semantic-interposition" > +sed -i 's/LIBVERSION = 2/LIBVERSION = 1/' src/Makefile > +%make_build > +cp src/libsemanage.so.1 ${RPM_BUILD_ROOT}/%{_libdir}/libsemanage.so.1 > > to the spec file in order to get libsemanage.so.1 which is shipped by > libsemanage.so.1 The parted dependency looks suspect; seems to be an incorrect linking with libsepol despite not directly calling any sepol functions. Aside from that, if we have to bump the so version and deal with compat packages anyway, should we go ahead and purge all of the other deprecated functions in libsepol and libsemanage (grep -ri deprecated libsepol libsemanage)?
