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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
