On 2020-09-21 12:08, Mark Wielaard wrote: > 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. It sounds very sensible :). Especially, as a workaround, in the situation that solving issues with duplicated shared libraries between packages was problematic. Thanks you guys for suggestions. Marcin > >>> 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 -- https://blog.solidsoft.pl/ - Working code is not enough _______________________________________________ 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
