Description of problem: Attempting to upgrade system, received error messages from DNF (see below). Version-Release number of selected component (if applicable): fc27-bash 4.4 ~# rpm -q sbcl sbcl-1.3.12-2.fc26.x86_64 fc27-bash 4.4 ~# rpm -q maxima-runtime-sbcl maxima-runtime-sbcl-5.38.0-4.fc26.x86_64 How reproducible: always Steps to Reproduce: 1.dnf -y upgrade 2. 3. Actual results: conflict messages, see below Expected results: successful upgrade Additional info: Error: Transaction check error: file /usr/lib/.build-id/49/26e332aa180952b8ffbceb00f6e08283dd2fa8 conflicts between attempted installs of sbcl-1.3.16-1.fc27.x86_64 and maxima-runtime-sbcl-5.39.0-6.fc27.x86_64
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.