On Fri, Oct 2, 2020 at 2:53 AM Nicolas Iooss <nicolas.iooss@xxxxxxx> 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.
