Daniel P. Berrangé <berrange@xxxxxxxxxx> a écrit: > On Mon, Nov 27, 2023 at 04:20:16PM +0100, Fabio Valentini wrote: >> On Fri, Nov 24, 2023 at 12:08 PM David King <amigadave@xxxxxxxxxxxxx> wrote: >> > >> > The latest released versions of libxml2 have a couple of important >> > changes in header files that have unintentionally caused some packages >> > to fail to build without modification, including: >> > >> > * several functions now accept or return a const xmlError struct >> > * cyclic dependencies in header files were fixed (by dropping some >> > includes) >> >> Sorry if the answer to this question is obvious - but shouldn't >> breaking changes like these cause an soname bump? >> I realize the whole "unintentional" part - but if these changes also >> affect ABI (the first sounds like it might do that), dependent >> packages would need to be rebuilt either way, wouldn't they? > > IIUC, the changes in libxml2 are API breaks, but not ABI breaks. > > ie the 'xmlError' parameter should have been const all along, > and apps would have been using it as if it were const. The > API was changed to correct this mistake and should be backcompat > with an pre-existing compiled app, but cause warnings on new > builds. Annoying, but an acceptable change without soname bump. For what it's worth, the ABI compatibility verifier caught this change between libxml2.so.2.11.5 and libxml2.so.2.12.0 and categorized it as being "ABI compatible" (i.e, not incompatible/breaking) at: https://artifacts.dev.testing-farm.io/b7d369b0-f288-4564-a331-48492c20bf8c/: [C] 'function int xmlCopyError(xmlErrorPtr, xmlErrorPtr)' at error.c:985:1 has some indirect sub-type changes: parameter 1 of type 'typedef xmlErrorPtr' changed: entity changed from 'typedef xmlErrorPtr' to compatible type 'const xmlError*' in pointed to type 'struct _xmlError': entity changed from 'struct _xmlError' to 'const _xmlError' type size hasn't changed I guess the important bit here is "entity changed from 'struct _xmlError' to 'const _xmlError'". So, yes, this is not an ABI incompatible change. Cheers, -- Dodji -- _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue