Curious build-id conflict while installing a package

[Robert-André Mauchin]

Hello,

While reviewing a package, I encountered an issue during the
installatiion phase of the review:

> Error: Transaction check error:
>   file /usr/lib/.build-id/5d/1c3c62276031587a6ac333785ee12f62218a86 
>     conflicts between attempted installs of wsjtx-1.8.0-0.1.rc1.fc28.x86_64 and
> hamlib-3.1-8.fc28.x86_64
>   file /usr/lib/.build-id/d3/602e131e4dc419e24969dd19b48829ff695210
>     conflicts between attempted installs of wsjtx-1.8.0-0.1.rc1.fc28.x86_64 and
> hamlib-3.1-8.fc28.x86_64
>  
I don't really understand what's causing this, nor how to fix it.

Some infos:
 - The wsjtx package depends on the hamlib package.
 - I don't know it this is relevant but both wsjtx and hamlib 
   have similarly named executables:
    + /usr/bin/rigctl and /usr/bin/rigctld for hamlib
    + /usr/bin/rigctl-wsjtx and /usr/bin/rigctld-wsjtx for wsjtx

Any help is appreciated.

Thanks,

Robert-André

[Mark Wielaard]

Hi,

Sorry, I missed this earlier.
Please let me know if it hasn't been resolved yet.

On Sat, 2017-09-02 at 12:04 +0200, Robert-André Mauchin wrote:
>  While reviewing a package, I encountered an issue during the
>  installatiion phase of the review:
>  
>  > Error: Transaction check error:
>  >  file /usr/lib/.build-id/5d/1c3c62276031587a6ac333785ee12f62218a86 
>  >    conflicts between attempted installs of wsjtx-1.8.0-
>  > 0.1.rc1.fc28.x86_64 and hamlib-3.1-8.fc28.x86_64
>  >  file /usr/lib/.build-id/d3/602e131e4dc419e24969dd19b48829ff695210
>  >    conflicts between attempted installs of wsjtx-1.8.0-
>  > 0.1.rc1.fc28.x86_64 and hamlib-3.1-8.fc28.x86_64 
Do you have the full build logs?

>  I don't really understand what's causing this, nor how to fix
> it.
>  
>  Some infos:
>   - The wsjtx package depends on the hamlib package.
>   - I don't know it this is relevant but both wsjtx and hamlib 
>     have similarly named executables:
>      + /usr/bin/rigctl and /usr/bin/rigctld for hamlib
>      + /usr/bin/rigctl-wsjtx and /usr/bin/rigctld-wsjtx for wsjtx 
One way this can happen is if a package literally copies a binary from
another package it just installed as a dependency and installs it under
a different name (it should make a symlink and add a Requires for the
other package).

Another way this can happen is if the the binaries are build from the
exact same source in the exact same build environment. rpmbuild should
prevent this by placing the buildsubdirs of the different packages in
different directories and hashing in the package versions into the
build-ids. But if the build "escapes" the buildsubdir and debuginfo
generation is disabled (no -g) it could still happen. In that case just
build with -g.

Cheers,

Mark

[Robert-André Mauchin]

On jeudi 14 septembre 2017 11:56:21 CEST Mark Wielaard wrote:
>  Hi,
>  
>  Sorry, I missed this earlier.
>  Please let me know if it hasn't been resolved yet.
>  
>  On Sat, 2017-09-02 at 12:04 +0200, Robert-André Mauchin wrote:
>  > While reviewing a package, I encountered an issue during the
>  > 
>  > installatiion phase of the review:
>  > > Error: Transaction check error:
>  > >  file /usr/lib/.build-id/5d/1c3c62276031587a6ac333785ee12f62218a86 
>  > >    conflicts between attempted installs of wsjtx-1.8.0-
>  > > 0.1.rc1.fc28.x86_64 and hamlib-3.1-8.fc28.x86_64
>  > >  file /usr/lib/.build-id/d3/602e131e4dc419e24969dd19b48829ff695210
>  > >    conflicts between attempted installs of wsjtx-1.8.0-
>  > > 0.1.rc1.fc28.x86_64 and hamlib-3.1-8.fc28.x86_64
>  
>  Do you have the full build logs?
>  
>  > I don't really understand what's causing this, nor how to fix it.
>  > 
>  > Some infos:
>  >  - The wsjtx package depends on the hamlib package.
>  >  - I don't know it this is relevant but both wsjtx and hamlib 
>  >    have similarly named executables:
>  >     + /usr/bin/rigctl and /usr/bin/rigctld for hamlib
>  >     + /usr/bin/rigctl-wsjtx and /usr/bin/rigctld-wsjtx for wsjtx
>  
>  One way this can happen is if a package literally copies a binary from
>  another package it just installed as a dependency and installs it under
>  a different name (it should make a symlink and add a Requires for the
>  other package).
>   
Hello,

Thank you for answering. From what I understand, this is exactly this, the 
package just provides renamed executables. We solved the issue by unbundling 
the duplicates since they are provided by the hamlib package.

Best regards,

Robert-André