On 4/28/20 5:06 PM, Lev Lamberov wrote:
Hi Jan,
Вт 28 апр 2020 @ 16:56 Jan Wielemaker <j.wielema...@vu.nl>:
Debian packaging of Asterisk and uWSGI uses such ABI hash towards third
party plugins, to alow them to be rebuilt as infrequently as possible.
See e.g. https://packages.debian.org/buster/uwsgi-plugin-php and
https://packages.debian.org/buster/asterisk-espeak (notice they depend
only indirectly on uwsgi/asterisk through a virtual ABI package name).
That is worth a try. I guess that implies that generating SWI-Prolog
(as package) also generates this hash. What kind of support would be
needed from SWI-Prolog to make this work? Some script/command to create
this hash for a particular system?
Let me emphasize that I do *not* consider this an important issue: Makes
sense if you simply consider your upstream official release version _is_
the "ABI", and if we in Debian choose to carry a patch which breaks that
"ABI" then that's our headache, not yours.
In practice, surely for now, this is just as good. The next version
packaged with Debian is typically the next stable release, which almost
always breaks full compatibility of the ABI wrt the previous stable.
Do you mean stable branches (like 8.0.x vs. 8.2.x) or revisions of a
given stable branch (8.0.1 vs. 8.0.2 vs. 8.0.3)? I personally would
expect no changes of ABI in a given stable branch and I think it is what
is typically expected. I mean no new features => no ABI change, no?
In most cases patch levels should not affect the ABI, but we have not
always been completely strict in this. A bug that requires an ABI
change (which happens) can happen in a patch level release. The
only real guarantee is that source code is fully compatible between
patch levels in the stable branch. We try to maintain as much as
possible binary compatibility and 99% of the cases we succeed in
that.
Cheers --- Jan
Cheers!
Lev
