Re: Removing unsupported AUTH_DES interfaces in libtirpc.
Hey... Thanks for all the input! On 10/19/20 1:21 PM, 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... > > This means I will need to change the SONAME for > libtirpc which will effect a large other packages. > > The last time I did this all hell broke out so > I'm trying to avoid that this time. > > So can someone please point me to the correct > way to change a SONAME without cause total chaos > It sounds like I'm trying to fix something that is not broken... and I too want want to keep the ABI as stable as possible. So I will nix the idea of changing the SONAME and just remove functions from the header files. Thanks again!! steved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Removing unsupported AUTH_DES interfaces in libtirpc.
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... If the internal encryption impl is removed, then any audit should already pass. > This means I will need to change the SONAME for > libtirpc which will effect a large other packages. > > The last time I did this all hell broke out so > I'm trying to avoid that this time. > > So can someone please point me to the correct > way to change a SONAME without cause total chaos 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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Removing unsupported AUTH_DES interfaces in libtirpc.
* Steve Dickson: > 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... Are you sure this is necessary? If there is no actual DES implementation, it won't matter for certification. > This means I will need to change the SONAME for > libtirpc which will effect a large other packages. Is this really necessary? I expect that a lot of projects migrated to libtirpc with an expectation that it would provide a similar level of ABI stability as glibc. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Removing unsupported AUTH_DES interfaces in libtirpc.
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Removing unsupported AUTH_DES interfaces in libtirpc.
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... This means I will need to change the SONAME for libtirpc which will effect a large other packages. The last time I did this all hell broke out so I'm trying to avoid that this time. So can someone please point me to the correct way to change a SONAME without cause total chaos tia, steved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
