Hi, On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote: > On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: > > Hi. There is an ongoing problem with conflicting build-ids in chromium > > and chromium-freeworld [1][2]: > > > Error: Transaction test error: > > > file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > > There is no clear idea why it happens, but my assumption is that due to > > the fact of building with the same source code (with similar patches), > > some generated shared libraries are the same which generates conflict(s). The error message could probably be improved. You might want to look at where the /usr/lib/.build-id/xx/yyyy symlinks are pointing at to get a better idea which binaries are identical between the packages. > > The quick look at the algorithm for build-id generation [3] doesn't > > answer my question what exactly is taken into account for their > > generation and more precisely is there is way to add some "fuzz" (having > > different buildroots doesn't help) to distinguish those libraries. The build-id is calculated over all relevant build environment bits (by the linker, not rpm). This includes the debuginfo in the original (not split) ELF file. The debuginfo contains the build paths (which should be different for different NVRs and include the compiler version and flags). This really should prevent identical build-ids whenever something is really build from source. Normally you only get identical build-ids when building the same source code in the same package with the same compiler flags. Identical build-ids between packages are really very rare and are often caused by some binary blob simply being copied between packages (is there a blob in the upstream tar ball that isn't build from source?) or if debuginfo (-g) is missing. > > To wrap up: > > 1. Is there a better way to deal with the aforementioned build-id > > conflicts than disable their generation on one side (with "%global > > _build_id_links none")? > > Instead of disabling entirely, you could tell rpm to put it all into > -debuginfo packages (ie the original debuginfo layout). Which would > still conflict, but fewer people are affected: > > %global _build_id_links alldebug Yes, that is a much better workaround than using none. > > 2. Maybe my assumption about the same generated shared libraries is > > wrong and there is something else what can be done to fix the root problem? > > That's exactly the cause, build-id's are engineered to reproducably > identify identical built objects, regardless of their location. Which > causes conflicts when the house rules of not shipping multiple idental > copies is broken (one might call this a feature). Yes, I would call this a feature :) > Short of unbundling the shared libraries, I guess a reasonable > workaround would be patching them to include some identifier string > based on the containing package name, which would cause them to have > different build_ids. If build from source and building with debuginfo that should already be the case because the build-id is calculated over the original debuginfo which contains the original (pre-debugedit) build paths, which should contain the package nvr in their name. So double check that things are build with -g. 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
