Re: Conflicting build-ids in chromium and chromium-freeworld

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux