Bug 1436856
| Summary: | build-id conflict between sbcl and maxima-runtime-sbcl | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | George R. Goffe <grgoffe> |
| Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | atu.guda, green, gryt2, ignatenko, kardos.lubos, mjw, packaging-team-maint, rdieter, vmukhame |
| Target Milestone: | --- | ||
| 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: | 2017-07-09 21:29:53 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: | |||
|
Description
George R. Goffe
2017-03-28 20:57:48 UTC
this is a bit beyond me, assigning to rpm for feedback,comment,guidance here on the build-id conflict. That should indeed not happen. Binaries in different packages should always have different build-ids. I'll investigate what is going on. Do those two binary packages come from the same source package? they come from separate packages: sbcl, maxima It may be a language quirk since sbcl is a lisp compiler (and maxima is all/mostly lisp code). Sorry for the delay. I had some trouble building the maxima package (btw there are several still running maxima build tasks in koji atm). And I still haven't figured out exactly what generated the two identical build-ids.
The sbcl package really should generate unique build-ids since it does a full package build including running debugedit which should have guaranteed the id was unique. The maxima package however defines debug_package %{nil} so doesn't run debugedit. That still shouldn't generate an identical build-id though. So I need to investigate a bit more how this can happen.
If you are stuck then please add "%global _build_id_links none" to the maxima.spec as workaround. That makes sure no build-id links are generated for any maxima package binary, so they cannot conflict with any of the sbcl package.
I just ran into this. It is probably related to this ticket. https://bugzilla.redhat.com/show_bug.cgi?id=1432372 Still happening with the latest packages in rawhide. *** Bug 1458416 has been marked as a duplicate of this bug. *** updating summary to mention build-id Added workaround to maxima packaging as suggested https://bugzilla.redhat.com/show_bug.cgi?id=1458416#c2 %changelog * Sun Jun 04 2017 Rex Dieter <rdieter> - 5.40.0-3 - workaround sbcl conflicts: _build_id_links none (#1458416#c2) The same effect with qcad-3.17.3.0-1.fc27.x86_64 and qt5-qtbase-gui-5.9.0-3.fc27.x86_64: file /usr/lib/.build-id/a2/ca48be6113d6c3ce277c9684103f0b6c3d53ee (In reply to Anton Guda from comment #10) > The same effect with qcad-3.17.3.0-1.fc27.x86_64 and > qt5-qtbase-gui-5.9.0-3.fc27.x86_64: > file /usr/lib/.build-id/a2/ca48be6113d6c3ce277c9684103f0b6c3d53ee That is interesting. Those two packages seem to include the exact same shared library (which explains why they have the exact same build-id). $ ls -lah `readlink -f */usr/lib/.build-id/a2/ca48be6113d6c3ce277c9684103f0b6c3d53ee ` -rwxr-xr-x. 1 mark mark 74K Jul 8 15:11 /tmp/rpms/qcad/usr/lib64/qcad/plugins/printsupport/libcupsprintersupport.so -rwxr-xr-x. 1 mark mark 74K Jul 8 15:12 /tmp/rpms/qt-base-gui/usr/lib64/qt5/plugins/printsupport/libcupsprintersupport.so $ cmp `readlink -f */usr/lib/.build-id/a2/ca48be6113d6c3ce277c9684103f0b6c3d53ee ` $ echo $? 0 The only difference is the installation directory: /usr/lib64/qcad/plugins/ vs /usr/lib64/qt5/plugins/ Of course even if they are build from the exact same sources with the exact same tools then their source build roots should be different because they are build from different source rpms. Which should mean their build-ids should actually be different. Looking into why not... (In reply to Mark Wielaard from comment #11) > (In reply to Anton Guda from comment #10) > > The same effect with qcad-3.17.3.0-1.fc27.x86_64 and > > qt5-qtbase-gui-5.9.0-3.fc27.x86_64: > > file /usr/lib/.build-id/a2/ca48be6113d6c3ce277c9684103f0b6c3d53ee > > That is interesting. Those two packages seem to include the exact same > shared library (which explains why they have the exact same build-id). > > $ ls -lah `readlink -f > */usr/lib/.build-id/a2/ca48be6113d6c3ce277c9684103f0b6c3d53ee ` > -rwxr-xr-x. 1 mark mark 74K Jul 8 15:11 > /tmp/rpms/qcad/usr/lib64/qcad/plugins/printsupport/libcupsprintersupport.so > -rwxr-xr-x. 1 mark mark 74K Jul 8 15:12 > /tmp/rpms/qt-base-gui/usr/lib64/qt5/plugins/printsupport/ > libcupsprintersupport.so > [...] > Looking into why not... I think this is some kind of packaging bug in qcad. It seems to have literally copied the qt5/plugins/printsupport/libcupsprintersupport.so file. If you look in the qcad.spec then you see that it does symlink the qt5 plugins for codecs, designer, imageformats and sqldrivers. So you have: $ ls -lah usr/lib64/qcad/plugins/sqldrivers/* lrwxrwxrwx. 1 mark mark 47 Jul 8 15:11 usr/lib64/qcad/plugins/sqldrivers/libqsqlite.so -> /usr/lib64/qt5/plugins/sqldrivers/libqsqlite.so Probably printsupport was missed and instead of symlinking the qt5/plugins/printsupport driver it was copied. @comment 9 Yes, sbcl and maxima happily co-exist now. Thank you. |