Hi Lev, On 04-03-2022 11:42, dogs...@riseup.net wrote:
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}
I already mentioned `eye` explicitly in my earlier messages, I wasn't worried about it. Please comment on the other reverse build dependencies (apart from eye and logol).
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?
As eye does seems like the way to go to me. Paul
OpenPGP_signature
Description: OpenPGP digital signature
