Yeah, apparently since libgit2 v0.99. Previously there was some other regex code built-in. But, as I replied to Pablo, you can build PCRE into the newer versions to avoid the runtime dependency.
On 10/13/20 1:36 AM, ducasse wrote:
Libgit depends on PCRE. O_o
On 13 Oct 2020, at 10:20, email@example.com wrote:
Hi Martin, thanks for testing it. Can you tell me the version / flavour of Debian are you using? Maybe we need to ship PCRE with the VM. I am not fun of that, but we need to do it until we can have a proper packaging for each Linux distribution (Esteban is working on having a nice OBS configuration for the VM extending what Holger has previously done). It takes time and a lot of testing, but the idea is to fix (or at least control better) the dependency nightmare between different Linux distributions.
On Tue, Oct 13, 2020 at 7:49 AM Martin McClure firstname.lastname@example.org wrote:
Thanks, this is great news.
Are there instructions on how to make P9 actually use the new version of libgit2? I see that the stable Linux VM for 9.0 does include "libgit126.96.36.199.so" but Pharo is still loading libgit2.so.0.25.1.
...this may be because Pharo's libgit188.8.131.52.so has not-found dependencies on libpcre.so.3 and libpcreposix.so.3.
I find Debian's versioning of libpcre somewhat confusing. The package "libpcre3" is the old libraries, and new stuff is supposed to use "pcre2." 2 is apparently newer than 3. At any rate PCRE library naming is rather distro-specific, and although I have the right packages installed, the libraries have different filenames.
But libgit2 is not supposed to have PCRE as a dependency. The source code for PCRE is included in the source for libgit2. Seems like it would be possible (and nice!) to compile the libgit184.108.40.206.so included with the VM to include the PCRE code internally, rather than depend on an external library.
On 10/12/20 2:26 AM, email@example.com wrote:
Hi, a later announcement (this have been done some months ago... but I never send the mail).
We have upgraded in Pharo 9 to use the latest stable version of Libgit. It required to have some improvements in Libgit to handle the updated version and also to support the previous version.
From the point of view of new features, it does not add new things. However, this version fixes a lot of existing problems in Libgit.
We can be sure this was a successful deployment as we don't have problems with it. We are really happy that this has been done transparently and keeping the working version with different configurations of images and VMs. As we should support new and old images, on the same VM. And also running new images in old VMs
-- Pablo Tesone. firstname.lastname@example.org