Paul Gevers писал 2022-03-04 00:46: > 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?
New upstream version of eye was uploaded the same day as new version of swi-prolog (in fact, after swi-prolog), and its autopkgtests pass with swi-prolog in unstable (on amd64, and these are "not a regression" on other architectures; they never were successful since at least Nov 2019, as I can see). And eye already does this: Package: eye Depends: swi-prolog-nox, swi-prolog-abi-${prolog:ABI}, ${misc:Depends} > 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. Hmmm... I'm not quite sure what would be the better option for logol and swi-prolog. If logol depends on swi-prolog-abi-binary-68, then change of ABI will require changing dependencies by hand. If logol depends on swi-prolog-abi-binary-$(prolog:ABI) as eye does (prolog:ABI should be handled in d/rules) and _not_ build-depend on it (but just build-depend on swi-prolog without version), then binNMU is possible. I think the latter is the easier way. What do you think, guys? Regards, Lev