| Message ID | 20200930145031.910190-4-plautrba@redhat.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/4] libsepol: Get rid of the old and duplicated symbols | expand |
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?
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 Petr
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)?
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
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.
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.
On Thu, Oct 1, 2020 at 7:48 PM Petr Lautrbach <plautrba@redhat.com> 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@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. 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
On Fri, Oct 2, 2020 at 2:53 AM Nicolas Iooss <nicolas.iooss@m4x.org> wrote: > > 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. My original understanding of library ABI compat requirements came from Ulrich Drepper's paper, https://www.akkadia.org/drepper/dsohowto.pdf Looks like Debian's policy is here: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries IIUC, if we follow the rules laid out by both, removing an old symbol version entirely is incompatible and requires a SONAME change. That said, commit c3f9492d7ff05bdc8581817655ad05bc1e1174b8 ("selinux: Remove legacy local boolean and user code") was technically an incompatible change; it left the symbols in place but made them always fail or ignore no-longer-used parameters, which isn't truly compatible, and we didn't change the SONAMEs then. I'd personally be ok with not changing the SONAME as long as these interfaces were only ever used by the selinux userspace code itself or only by really ancient code that is no longer in use by any supported distribution but I don't think that flies with e.g. the Debian policy.
On Fri, Oct 2, 2020 at 4:50 PM Stephen Smalley <stephen.smalley.work@gmail.com> wrote: > > On Fri, Oct 2, 2020 at 2:53 AM Nicolas Iooss <nicolas.iooss@m4x.org> wrote: > > > > 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. > > My original understanding of library ABI compat requirements came from > Ulrich Drepper's paper, > https://www.akkadia.org/drepper/dsohowto.pdf > > Looks like Debian's policy is here: > https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries > > IIUC, if we follow the rules laid out by both, removing an old symbol > version entirely is incompatible and requires a SONAME change. That > said, commit c3f9492d7ff05bdc8581817655ad05bc1e1174b8 ("selinux: > Remove legacy local boolean and user code") was technically an > incompatible change; it left the symbols in place but made them always > fail or ignore no-longer-used parameters, which isn't truly > compatible, and we didn't change the SONAMEs then. > > I'd personally be ok with not changing the SONAME as long as these > interfaces were only ever used by the selinux userspace code itself or > only by really ancient code that is no longer in use by any supported > distribution but I don't think that flies with e.g. the Debian policy. Thanks for the details. Debian policy makes sense and I agree with bumping the version in the SONAME. Nicolas
diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile index a0eb3747d74b..ab6cae51f5c3 100644 --- a/libsemanage/src/Makefile +++ b/libsemanage/src/Makefile @@ -32,7 +32,7 @@ YACC = bison YFLAGS = -d VERSION = $(shell cat ../VERSION) -LIBVERSION = 1 +LIBVERSION = 2 LIBA=libsemanage.a TARGET=libsemanage.so
It's due to the previous ABI incompatible change Signed-off-by: Petr Lautrbach <plautrba@redhat.com> --- libsemanage/src/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)