Re: [PATCH 4/4] libsemanage: Bump libsemanage.so version

[Petr Lautrbach <plautrba@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3067 bytes --]

On Thu, Oct 01, 2020 at 10:18:35AM -0400, Stephen Smalley wrote:
> On Wed, Sep 30, 2020 at 11:56 AM Petr Lautrbach <plautrba@redhat.com> 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@redhat.com> wrote:
> > > >
> > > > It's due to the previous ABI incompatible change
> > > >
> > > > Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
> > >
> > > 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)?
> 

I'd like to ship compat only for short time until all dependent components are
rebuilt.

Purging deprecated functions could have much bigger impact than this patchset as it affects API. With
this change, it's generally enough to rebuild a component. If we drop functions
and change API, different software could stop work. There are only few packages
using libsepol and libsemanage directly, but there might be much bigger group of
python or ruby scripts using deprecated symbols like matchpathcon*()

Petr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]