Open philrz opened 3 years ago
I have the same case during rpm package installation
sudo rpm -ihv --nodeps zui-1.4.1.x86_64.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] file /usr/lib/.build-id/51/74642779eb830026a665bff7d1869207a574ac from install of zui-1.4.1-1.x86_64 conflicts with file from package xmind-vana-23.11.4336-202311170221.x86_64 file /usr/lib/.build-id/7b/bde14ca6192338b4c5d44af06e90ca06276940 from install of zui-1.4.1-1.x86_64 conflicts with file from package xmind-vana-23.11.4336-202311170221.x86_64 file /usr/lib/.build-id/8b/060bea4cd4260d05f778be1856691d20377fcb from install of zui-1.4.1-1.x86_64 conflicts with file from package xmind-vana-23.11.4336-202311170221.x86_64 file /usr/lib/.build-id/90/9d0b5007ba7bf20d9e4205235b3fe5a9f3309e from install of zui-1.4.1-1.x86_64 conflicts with file from package xmind-vana-23.11.4336-202311170221.x86_64
Thanks for letting us know @zmiimz. We unfortunately have not been able to fix this. Please do let us know if you were able to workaround the problem with the --replacefiles
approach described above or any other ways.
Per https://github.com/brimdata/zui/pull/3084#issuecomment-2159007093, I've noticed that this can also occur when attempting to install a Zui RPM when a Zui Insiders release is already installed.
A community user reported on Slack:
This failure was unfamiliar, so I dug into it on a scratch CentOS 8 VM. It does seem like a legitimate collision, unfortunately. I started with having only Brim installed and I could see what that symlink is pointing at:
Then I uninstalled Brim and installed Volatility3 and I can see that's pointing at a different file:
The files are definitely different though. Having copied them out of those locations:
Having just learned about this for the first time, I don't claim a thorough understanding of what these "build-id" paths are for either, but quick web searches seem to imply it involves "unique identification of binaries" (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/developer_guide/compiling-build-id). Using the commands they show there that generate the hashes, indeed, it seems to be true:
I think that leads me to a theory, though. This
suricata-update
binary happens to have been generated by usingpyinstaller
(https://www.pyinstaller.org/) to "freeze" the Python code in which Suricata Update is written, since that allows us to avoid having Python installed and with the correct dependencies on all users systems. And I see that Volatility also claims to be a Python project, so perhaps it's similarly packaged and that trips up the hashing somehow. Perhaps the hashing doesn't "see" the Python code parts that make each overall file different, so it comes away with a sense that they're equivalent? That's just a theory though.I found a thread at https://stackoverflow.com/questions/21246680/disable-yum-transaction-check-for-file-conflict where people were debating whether it's safe to let these stomp on each other to resolve conflicts. I can't say with certainty what the correct answer is, but FWIW, since my CentOS 8 VM is just a scratch one, I did try
sudo rpm -i --replacefiles brim_x86_64-v0.24.0.rpm
while Volatility was already installed and it did, indeed, install without complaint and seemed to launch ok. I don't know Volatility well enough to check its health, however. The user that reported the problem did use this workaround and claimed that both Brim and Volatility seemed to be working ok for them.I'm not sure what we might do to better avoid this class of problem in the future. A few that come to mind:
For now I'll hold this issue open in the event other users stumble onto it. If anyone does and reads this, please add a comment with details of your experience.