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@xxxxxxxxxx> 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@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)? > > > > > > > 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:
signature.asc
Description: PGP signature
