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 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.
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
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).
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.
- Panu -
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869037
[2] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5743
[3] -
https://github.com/rpm-software-management/rpm/blob/505fe16f863f83637c9577417a7ae959df674a61/build/files.c#L1803
[4] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5758
Marcin
P.S. There are cases where it would be best to have those two packages
installed simultaneously [4].
_______________________________________________
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
