Hello Joerg, > We are not back.
to be honest, yes we are :) > > Between 1.0.30 and 1.0.31 are the following 7 symbols are not longer > available: > > #MISSING: 1.0.31# testing_append_commands_node@Base 1.0.29 > #MISSING: 1.0.31# testing_known_commands_input_failed@Base 1.0.29 > #MISSING: 1.0.31# testing_last_known_seq@Base 1.0.29 > #MISSING: 1.0.31# testing_record_backend@Base 1.0.29 > #MISSING: 1.0.31# testing_xml_doc@Base 1.0.29 > #MISSING: 1.0.31# testing_xml_next_tx_node@Base 1.0.29 > #MISSING: 1.0.31# testing_xml_path@Base 1.0.29 > > This ABI changes are not backward-compatible. And so the change are required. > So, to explain: If you think they are not backward-compatible, you should rename the package, but not provide the old SONAME as transitional package, otherwise you are doing a mistake In this case, the symbols were private, and incorrectly exposed outside, so removing them is "safe" as long as nobody uses them. When I sponsored the package for you, even if I forgot to write that on the RFS bug, I had a discussion about this with some other DDs, and we agreeded that this wasn't worth a SONAME change, because the end user applications were still ABI-safe. So, this is why I asked you to restore the old package name, and make it transitional, to avoid people being forced to upgrade to a new library SONAME without a real SONAME change. This way, we made almost "everybody" happy, or at least improved the status quo for some bits. (the real world fix was to ignore lintian, or to not start with a wrong soname, but this history now) So, yes, the ABI changed, but the change was not reflected into a real issue for any Debian application, or any custom-built application. I honestly think we should just move forward, and change the soname again if a the library changes in the future. G.
