Hi Lev, On 03-03-2022 08:46, dogs...@riseup.net wrote:
swi-prolog package (namely, swi-prolog-core) provides an easy way to require some particular ABI since 8.2.0+dfsg-2 uploaded on Jun 9, 2020. Specifically, in this case logol requires version 67 of binary ABI (pre-compiled Prolog code), where the version of swi-prolog in unstable is at version 68. In case of logol, its fixed version needs to depend on swi-prolog-binary-68 (again, provided by swi-prolog-core). In this case it will be easier to track problems with ABI changes.There are more ABI stuff in swi-prolog which can be tracked the same way. It is documented in d/Debian.NEWS and d/README.Debian and there are references to SWI-Prolog upstream reference guide. More specifically, swi-prolog provides 5 virtual packages, each of them containing (a part) of some specific ABI version claimed by the current swi-prolog version. All these components are extensively documented in SWI-Prolog upstream reference guide. These virtual packages were introduced to prevent the same ABI-incompatibility problems with another Debian package, eye.
Do you confirm that this ABI change doesn't effect the other reverse build dependencies of src:swi-prolog? If that's the case I'm fine with removing the block. But I'm afraid (without checking from my side) that the other package don't have the right virtual ABI package in their dependencies. If they do, wouldn't they need a rebuild too?
Also, if logol is already doing the right thing, shouldn't you as the uploader of swi-prolog request a binNMU for logol to enable your package to migrate at all? I mean, I would expect the migration to become blocked by uninstallability of logol in testing without a rebuild.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
