Hi Andy,
(Please do put me on CC, I do try to read all of devel list, but it is easy to miss something)
On Tue, May 02, 2023 at 11:42:30AM -0000, Andy Li wrote:
Sorry for the late reply. I just got back to this issue.
In general this (should) only happen if the binaries are really identical (e.g. when one of the packages build requires the other, but instead of linking/rebuilding some sources it simply copies a binary directly).
The build-id is (also) derived from the full nvra. So really cannot be identical even if the sources are. But this relies on the binaries being build with debuginfo. So maybe some code isn't build with -g?
I *think* both neko and haxelib were built with debuginfo, as I can find `-g` in the logs.
Yes, that doesn't seem to be the issue.
The fetching the latest x86_64 packages haxe-4.2.5-5.fc38.x86_64.rpm nekovm-2.3.0-11.fc38.x86_64.rpm you can see that the conflicting build-id is /usr/lib/.build-id/b8/acf4f8271b78cd6dca636cb5b877c5c64f47f4 Which points to /usr/bin/haxelib in the first package and to /usr/bin/neko in the second.
And if you compare them then they are indeed the same ELF file: $ eu-elfcmp usr/bin/neko usr/bin/haxelib $ echo $? 0
But they aren't really the same: $ cmp usr/bin/neko usr/bin/haxelib cmp: EOF on usr/bin/neko after byte 24632, in line 29
So after the ELF file data there is something else.
What I suspect is happening is that haxelib is really just a direct copy of the neko binary with some bytecode added.
Cheers,
Mark