On Mon, Oct 19, 2020 at 01:21:35PM -0400, Steve Dickson wrote: Hi, there are three semi-independent ways how to remove an interface: 1. functional stubbing out (which you said is already done) 2. removal of the function from headers 3. removal of the function from ABI and the resulting required SONAME change (1. affects programs that use the function at runtime. 2. affects programs which use the function during compilation. 3. affects all programs that use the library.) Part 1. is already done, and we are discussing 3.: IMHO the best option is not to this at all. SONAME changes in libraries low in the stack are simply quite problematic. It is OK for leaf libraries with a limited number of users, but even there barely so. While we can rebuild distro packages, user programs will still require relinking, making users angry. What about just doing 2. instead, so that we can make certain that *new* builds are not trying to use those functions. glibc doesn't change SONAME, libsystemd doesn't change SONAME, etc. We have symbol versioning, which allows precise dependencies on specific symbols. Use that instead, just never remove any symbols, but only add new ones. Symbol versioning is nicely integrated with rpm dependency autogenerators, so packages get granular dependencies on the specific symbols they use. Returning to the original question: if you absolutely must do an incompatible SONAME, then please provide a compat package with the old SONAME. Maybe it could even be built from the same sources. But it seems that the only motivation in this particular case is legal pretend-work (since the functions were already stubbed out, just removing the stub has no functional effect except ticking off a box somewhere). That just doesn't seem like a good enough motivation to go through the work for both packagers and users. Zbyszek

On Mon, Oct 19, 2020 at 01:21:35PM -0400, Steve Dickson wrote: If the internal encryption impl is removed, then any audit should already pass. Simply don't change it. There is no serious harm in having APIs exposed in the library that are no-op stubs always returning an error. You can remove the functions from the header files so that future apps will fail to build, while leaving the APIs in the library so that existing linked apps do not break. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|