Bug 1986382
| Summary: | failed symlink(File exists) .build-id error in Processing files with fedora-34-x86_64 mock config | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Anoop C S <anoopcs> | ||||
| Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | swm-qe | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 8.4 | CC: | ffesti, mdomonko, packaging-team-maint | ||||
| Target Milestone: | beta | Flags: | pm-rhel:
mirror+
|
||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-08-10 15:31:36 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Anoop C S
2021-07-27 12:13:34 UTC
Do I have to provide anything extra as debug information to investigate the issue? This issue is probably cause by there being two copies of a file which share the same build id (aka are identical) - one of the copies being /usr/lib64/python\ 3.9/site-packages/samba/dsdb.cpython-39-x86_64-linux-gnu.so The failing symlink is trying to point from the buildid (think hash of the file) to the two locations at once. This can be avoided by getting rid of one of the copies - e.g. by replacing it with a symlink the the other copy - or by disabling debuginfo generation. The later one preventing debugging for the contents of the package and other programs using the libraries - obviously. It turns out the root cause here is an old, known issue in RPM's build-id generation logic, more details here: https://bugzilla.redhat.com/show_bug.cgi?id=878863 Basically, when using %exclude on files that are not packaged in any other subpackage in the same .spec file, RPM won't complain about unpackaged files and fail as it normally would, however the build-id generator will get confused and produce unexpected results. In my testing with a simple spec file that contains: %files %{_bindir}/foo %exclude %{_bindir}/foo rpmbuild printed a warning saying "File listed twice: /usr/lib/.build-id/a1/e0c933eef9fa99e3b98ac6c42a927179846281" and the build finished successfully. However, inspecting the binary package, this filename was a dangling symlink (because /usr/bin/foo had been excluded). In the case of this samba package, however, the build failed with the "failed symlink: File exists" error; that could indicate that the build-id generator didn't detect the duplicate and just went ahead to process the same file twice. I'm not quite sure why in the samba case the duplicate wasn't recognized, however I'm pretty sure the root cause was the same as in the previous example. Even though the Bug 878863 is CLOSED, it's a valid defect in RPM which we're tracking upstream: https://github.com/rpm-software-management/rpm/issues/1622 Either way, the "fix" here is to simply not use %exclude on unpackaged files in the .spec file [1]. After all, that's not how the %exclude directive is supposed to be used (see Panu's comments in Bug 878863). Specifically, it's these two .so files: %exclude %{python3_sitearch}/samba/dsdb.*.so %exclude %{python3_sitearch}/samba/dsdb_dns.*.so These are not packaged in any other subpackage, yet they remain the buildroot (triggering the above RPM bug), so to avoid this, you need to remove them in the %install section. I tried to apply this change to the SRPM you provided above (thanks!) and it did resolve the problem for me. That said, I'm closing this BZ as a DUPE. [1] https://github.com/gluster/samba-integration/blob/samba-build/packaging/samba-master.spec.j2 *** This bug has been marked as a duplicate of bug 878863 *** Just a side note - I did a git blame on the above spec file and it seems the following commit introduced this issues: https://github.com/gluster/samba-integration/commit/fe4d4d02491ab0ee892cf97c69fcd66964a4aa19 Another side note: As part of the debugging session, Anoop also pointed out to me that with the fedora-33 mock config, the build actually passes just fine - so in the hopes of understanding this issue better, I tried that... and indeed, it worked! However, I got the following warnings, which confirm the suspected root cause described above: warning: File listed twice: /usr/lib/.build-id/81/ef29a63209c5d5940f8d20cf46b5079b6a24f9 warning: File listed twice: /usr/lib/.build-id/9b/dc1e42c3fb842a08d070cabb45e297b2891ce8 |