Hi Jonas,
On 4/28/20 4:42 PM, Jonas Smedegaard wrote:
Hi Jan,
Quoting Jan Wielemaker (2020-04-28 16:12:32)
A saved state makes sense for this scenario. Now I do not really
understand what the problem is. The eye package depends on some exact
version of SWI-Prolog, but it is not uncommon for one package to
require some specific version of a library, no?
Is the real problem that we cannot two versions of SWI-Prolog
installed side-by-side, so eye can depend on a specific version? That
can be fixed using -DSWIPL_VERSIONED_DIR=ON to the CMake configure,
which installs swi-prolog in /usr/lib/swi-prolog-<version>. Now we
get the problem that Debian likes -DSWIPL_INSTALL_IN_LIB=ON,
installing the shared object in /usr/lib, but this too should be
versioned, no?
The above seems one way out (but probably requires some work). Another
is to have the post-install script of eye create the saved state.
Finally, we could use caching by having eye.sh test for a state at
some cache location (e.g., ~/.cache/swi-prolog/states/eye.pvm) and
using this if available or first call swipl to create the saved state.
Would be nice to have an overall preferred solution for package
managers to deal with SWI-Prolog saved states. I think all three above
are viable, each with pros and cons and no clear winner.
The problem - which I consider a minor one - is to know for certain when
it is needed to regenerate an image.
I prefer that the binary package for eye contains only the generated
image (i.e. the eye source to generate that image is part of the Debian
_source_ package but not included in the _binary_ *.deb). What I would
then see as ideal would be if the binary package could know which exact
ABI of SWI Prolog it was tied to, so that it was known when it was
needed to regenerate the package.
You mentioned in a precviously quoted email that the ABI consist of two
parts, one of them being a hash of a VM and the other being a set of
variables. I would gues that an ABI could then be some chars of the VM
hash + some chars of a hash of those variables.
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.
It would make sense if we could establish a working series of patches
on a stable release that is guaranteed not to break the ABI. I'm
afraid the project never managed to make this work. Projects that
must rely on a stable version typically backport relevant fixes
themselves or found some other way to ensure access to a version
that is (for the project) the right mix between stability, features
and bugs.
Cheers --- Jan
