Re: Conflicting build-ids in chromium and chromium-freeworld
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