On Mon, Oct 19, 2020 at 01:21:35PM -0400, Steve Dickson wrote: > Hello, > > About a year ago I stub out the interfaces > and had them return an error if called. > No one has complained... > > This time I would like to remove interfaces > so there will be no support whatsoever to > pass some upcoming audits... 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. > This means I will need to change the SONAME for > libtirpc which will effect a large other packages. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx