[Debian-med-packaging] Bug#1006384: closed by Debian FTP Masters <ftpmaster at ftp-master.debian.org> (reply to Olivier Sallou <osallou at debian.org>) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)

dogsleg at riseup.net dogsleg at riseup.net
Fri Mar 4 10:42:36 GMT 2022


Paul Gevers писал 2022-03-04 00:46:
> Hi Lev,
> 
> On 03-03-2022 08:46, dogsleg at 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



More information about the Debian-med-packaging mailing list