On Thu, Oct 1, 2020 at 7:48 PM Petr Lautrbach <plautrba@xxxxxxxxxx> wrote: > > 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. Hello, I have another question: why is bumping the .so version needed? As we are not changing the ABI of a "linked symbol" (thanks to using versioned symbols, with .map files), if we do not bump the .so version, programs that were built with libsepol.so from years ago will just stop working due to missing symbols, with an error message which will be quite clear (and this only if they were using deprecated symbols). In my humble opinion, bumping the .so version is most required when the calling convention of a non-versioned symbol changes, but this leads to unexpected execution paths. Nevertheless I did not spend time to search for a document that would explain why bumping the .so version would be recommended when removing symbols. If you know one, could you please add a reference to it in the commit description ("Following guidelines from https://...) and/or to some documentation? >From a "distro maintainer point of view" (for Arch Linux), having just spent a considerable amount of time due to breaking changes in the last release of PAM, I am not eager to spend time dealing with finding clever ways to smoothly upgrade the system if there is no easy&straightforward way to do this. Introducing a transition package for each library which is bumped is acceptable to me, but if the release after the next one bumps the version again, introducing another set of transition packages will begin to be quite painful. In short: I agree to remove the deprecated functions in order to "bump the .so version only once", as suggested. Cheers, Nicolas
