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

[Petr Lautrbach <plautrba@redhat.com>]

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

On Thu, Oct 01, 2020 at 01:08:27PM -0400, Stephen Smalley wrote:
> On Thu, Oct 1, 2020 at 12:56 PM Petr Lautrbach <plautrba@redhat.com> wrote:
> >
> > 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*()
> 
> Yes, I just meant libsepol and libsemanage deprecated functions not
> libselinux (so not matchpathcon) since you are already bumping the so
> version.  But it's fine if you don't want to do it at the same time.
> 

I see, I missed that point, sorry. It seems to be reasonable, but I'll check it
again tomorrow.

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