Hey, apparently some ELF files are identical between Fedora's pypy3.7-libs and pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error: file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not "two packages bundle the same thing" but rather "two packages built in a different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-seed%s+"', rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could redefine in a less cryptic and fragile way?
The time had to come, when two packages would generate the same hash.
I was hit by: --- Error: Transaction test error: file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64 and skypeforlinux-8.79.0.95-1.x86_64 --- some time ago but since neither is a package maintained by Fedora Project maintainers, no one gave a damn about the core of the issue. That time, I got one of the apps as a Flatpak instead, but not all packages have such workarounds at hand.
--
Michal Schorm Software Engineer Core Services - Databases Team Red Hat
--
On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok mhroncok@redhat.com wrote:
Hey, apparently some ELF files are identical between Fedora's pypy3.7-libs and pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error: file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not "two packages bundle the same thing" but rather "two packages built in a different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-seed%s+"', rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could redefine in a less cryptic and fragile way?
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, 2022-02-14 at 10:34 +0100, Michal Schorm wrote:
The time had to come, when two packages would generate the same hash.
I was hit by:
Error: Transaction test error: file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64 and skypeforlinux-8.79.0.95-1.x86_64
some time ago but since neither is a package maintained by Fedora Project maintainers, no one gave a damn about the core of the issue. That time, I got one of the apps as a Flatpak instead, but not all packages have such workarounds at hand.
yeah , thank you for reminder these cases (with electron apps)
we fixed with `%global debug_package %{nil}`
--
Michal Schorm Software Engineer Core Services - Databases Team Red Hat
--
On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok mhroncok@redhat.com wrote:
Hey, apparently some ELF files are identical between Fedora's pypy3.7- libs and pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error: file /usr/lib/.build- id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/40/682aae1fc61eaa03230eac9033407ce96488c9 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/c9/e94d839699198b0e87c334f8e03160fec054de from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not "two packages bundle the same thing" but rather "two packages built in a different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%- id%-seed%s+"', rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could redefine in a less cryptic and fragile way?
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, 2022-02-14 at 11:28 +0000, Sérgio Basto wrote:
On Mon, 2022-02-14 at 10:34 +0100, Michal Schorm wrote:
The time had to come, when two packages would generate the same hash.
I was hit by:
Error: Transaction test error: file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b conflicts between attempted installs of discord-0.0.16- 1.fc35.x86_64 and skypeforlinux-8.79.0.95-1.x86_64
some time ago but since neither is a package maintained by Fedora Project maintainers, no one gave a damn about the core of the issue. That time, I got one of the apps as a Flatpak instead, but not all packages have such workarounds at hand.
yeah , thank you for reminder these cases (with electron apps)
we fixed with `%global debug_package %{nil}`
is fixed with %global _build_id_links none
--
Michal Schorm Software Engineer Core Services - Databases Team Red Hat
--
On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok mhroncok@redhat.com wrote:
Hey, apparently some ELF files are identical between Fedora's pypy3.7- libs and pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error: file /usr/lib/.build- id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/40/682aae1fc61eaa03230eac9033407ce96488c9 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/c9/e94d839699198b0e87c334f8e03160fec054de from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build- id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not "two packages bundle the same thing" but rather "two packages built in a different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%- id%-seed%s+"', rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could redefine in a less cryptic and fragile way?
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Michal Schorm wrote:
The time had to come, when two packages would generate the same hash.
Well, yes, depending on hash codes being globally unique is broken by design. Hash collisions exist. They can happen both by accident (because hash functions cannot possibly be injective because the range is smaller than the domain) and by design (when really the same binary is compiled under the same conditions twice, or even a binary from a third party is bundled by multiple proprietary RPMs, which I suspect is what happened for discord and skypeforlinux).
The build-id concept needs to be completely redesigned to not rely on hash codes. We should go by file name or even package EVR + file name (as a complete string, not hashed) instead. (In fact, that used to be how things worked before build-ids were introduced, and there were never any issues with that approach.)
Kevin Kofler
On 14. 02. 22 10:34, Michal Schorm wrote:
The time had to come, when two packages would generate the same hash.
I was hit by:
Error: Transaction test error: file/usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64 and skypeforlinux-8.79.0.95-1.x86_64
some time ago but since neither is a package maintained by Fedora Project maintainers, no one gave a damn about the core of the issue. That time, I got one of the apps as a Flatpak instead, but not all packages have such workarounds at hand.
That's because they both ship the same electron binary.
On Tue, 2022-02-15 at 10:33 +0100, Miro Hrončok wrote:
On 14. 02. 22 10:34, Michal Schorm wrote:
The time had to come, when two packages would generate the same hash.
I was hit by:
Error: Transaction test error: file/usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b conflicts between attempted installs of discord-0.0.16- 1.fc35.x86_64 and skypeforlinux-8.79.0.95-1.x86_64
some time ago but since neither is a package maintained by Fedora Project maintainers, no one gave a damn about the core of the issue. That time, I got one of the apps as a Flatpak instead, but not all packages have such workarounds at hand.
That's because they both ship the same electron binary.
Right , so ? two package can't ship the same binary on Fedora ?
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org 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/packaging@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 15. 02. 22 15:31, Sérgio Basto wrote:
On Tue, 2022-02-15 at 10:33 +0100, Miro Hrončok wrote:
On 14. 02. 22 10:34, Michal Schorm wrote:
The time had to come, when two packages would generate the same hash.
I was hit by:
Error: Transaction test error: file/usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b conflicts between attempted installs of discord-0.0.16- 1.fc35.x86_64 and skypeforlinux-8.79.0.95-1.x86_64
some time ago but since neither is a package maintained by Fedora Project maintainers, no one gave a damn about the core of the issue. That time, I got one of the apps as a Flatpak instead, but not all packages have such workarounds at hand.
That's because they both ship the same electron binary.
Right , so ? two package can't ship the same binary on Fedora ?
I never said that. What I meant is that that problem is known and I need to help with a different problem.
On Tue, 2022-02-15 at 15:46 +0100, Miro Hrončok wrote:
On 15. 02. 22 15:31, Sérgio Basto wrote:
On Tue, 2022-02-15 at 10:33 +0100, Miro Hrončok wrote:
On 14. 02. 22 10:34, Michal Schorm wrote:
The time had to come, when two packages would generate the same hash.
I was hit by:
Error: Transaction test error: file/usr/lib/.build- id/34/feaa549462e8818baa0629ce11da344465882b conflicts between attempted installs of discord-0.0.16- 1.fc35.x86_64 and skypeforlinux-8.79.0.95-1.x86_64
some time ago but since neither is a package maintained by Fedora Project maintainers, no one gave a damn about the core of the issue. That time, I got one of the apps as a Flatpak instead, but not all packages have such workarounds at hand.
That's because they both ship the same electron binary.
Right , so ? two package can't ship the same binary on Fedora ?
I never said that. What I meant is that that problem is known and I need to help with a different problem.
I was being ironic, I didn't want to say that either, sorry.
But I think the root of the problem is the same, .build-id hash be the same is not a coincidence .
Also we have old bug reports about .build-id hash conflicts , IIRC .
Best regards,
I've realized I've sent this initially to rpm-list-requests and not rpm-list. Sorry about that.
On 13. 02. 22 14:11, Miro Hrončok wrote:
Hey, apparently some ELF files are identical between Fedora's pypy3.7-libs and pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error: file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not "two packages bundle the same thing" but rather "two packages built in a different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-seed%s+"', rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could redefine in a less cryptic and fragile way?
Apparently, changing --build-id-seed breaks debugsourcefiles.list:
+ /usr/bin/find-debuginfo -j6 --strict-build-id -m -i --build-id-seed 3.7-7.3.7-5.fc37 --unique-debug-suffix -7.3.7-5.fc37.x86_64 --unique-debug-src-base pypy3.7-7.3.7-5.fc37.x86_64 --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 -S debugsourcefiles.list /builddir/build/BUILD/ extracting debug info from /builddir/build/BUILDROOT/pypy3.7-7.3.7-5.fc37.x86_64/usr/lib64/pypy3.7/lib_pypy/_curses_cffi.pypy37-pp73-x86_64-linux-gnu.so extracting debug info from ... original debug info size: 2616kB, size after compression: 2468kB /usr/bin/sepdebugcrcfix: Updated 15 CRC32s, 0 CRC32s did match. 6363 blocks
...
Processing files: pypy3.7-debugsource-7.3.7-5.fc37.x86_64 RPM build errors: error: Could not open %files file /builddir/build/BUILD/pypy3.7-v7.3.7-src/debugsourcefiles.list: No such file or directory Could not open %files file /builddir/build/BUILD/pypy3.7-v7.3.7-src/debugsourcefiles.list: No such file or directory
Is that a bug, or ame I doing something wrong?
That log is from https://src.fedoraproject.org/rpms/pypy3.7/pull-request/16
On Sun, 2022-02-13 at 14:11 +0100, Miro Hrončok wrote:
Hey, apparently some ELF files are identical between Fedora's pypy3.7-libs and pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error: file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64 file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not "two packages bundle the same thing" but rather "two packages built in a different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
yes , I like your solution , as talked in previous messages we have a long historical of .build-id file conflicts , which we should prevent
What are the side effects for changing the seed like this?:
%global __debug_install_post \ %{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%- seed%s+"', rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could redefine in a less cryptic and fragile way?
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure