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#L177
>
> %{?_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 -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure