Bug 1319440

Summary: gcc.i686 doesn't conflict with gcc.x86_64 - both packages being pulled for x86_64 builds
Product: [Fedora] Fedora Reporter: Mihai Moldovan <ionic>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: davejohansen, jakub, jwakely, law, mpolacek, vedran
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 18:46:25 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 Flags
FC22 x2goclient mock build log
none
repoquery --whatrequires gcc.i686 none

Description Mihai Moldovan 2016-03-20 05:10:44 UTC 
Created attachment 1138186 [details]
FC22 x2goclient mock build log

On x86_64, both gcc.i686 and gcc.x86_64 are pulled during mock builds for FC 22, 23 and rawhide, leading to a build error such as:

Transaction Check Error:
  file /usr/libexec/getconf/default conflicts between attempted installs of gcc-5.3.1-2.fc22.i686 and gcc-5.3.1-2.fc22.x86_64


This can be worked around by adding "exclude=gcc.i686" to the fc{22,23,rawhide}-x86_64 mock config files, but the packages should actually conflict if they cannot be installed side-by-side.

.spec file used to build the project: http://code.x2go.org/gitweb?p=x2goclient.git;a=blob_plain;f=x2goclient.spec;h=b142974902c404a5fc93c17adac648423d8e25c6;hb=HEAD

At the same time, I do have to admit that I'm using the {mock,rpm,yum} versions as packaged in Debian Jessie (i.e., mock base version 1.1.33, rpm base version 4.11.3, yum base version 3.4.3 with Debian patches), but maybe there's something that can be done in the Fedora repositories to get rid of the issue.

Some background regarding this issue: it first started a few month ago in rawhide, with FC 22 and 23 being unaffected at that time, than successively propagated to FC 23 and FC 22. I'd assume the change is at least two month old, I just didn't have any time to write a proper bug report for this yet.

The fc{22,23,rawhide}-i686 mock config files do not need any "exclude=gcc.x86_64" line, suggesting that the i686 repo is not affected (or at least does not pull the x86_64 package automatically.)

I'll also add a more complete build log as a compressed attachment.
Comment 1 Jakub Jelinek 2016-03-20 11:31:14 UTC 
Almost no packages have similar conflicts between different arch versions of the same packages.  The bug is in whatever pulled gcc.i686 into x86_64 distro, that should be fixed.  gcc is not a multilib package (most of the lib* subpackages of gcc are though).
Comment 2 Mihai Moldovan 2016-03-21 23:33:44 UTC 
I know that most lib packages are multilib and multiple arch versions can be installed at the same time, but the gcc package being different from that.

Is the problem that some other package explicitly depends upon gcc.i686 and the gcc.i686 package was pulled into the x86_64 repository?

Executing "repoquery --whatrequires gcc.i686" in my FC22 VM to find all packages that depend upon gcc.i686 in the x86_64 repository returns the output to-be-attached.

Is there anything else I can do to help find the culprit?
Comment 3 Mihai Moldovan 2016-03-21 23:34:34 UTC 
Created attachment 1138824 [details]
repoquery --whatrequires gcc.i686
Comment 4 Vedran Miletić 2016-06-02 01:18:04 UTC 
(In reply to Jakub Jelinek from comment #1)
> Almost no packages have similar conflicts between different arch versions of
> the same packages.  The bug is in whatever pulled gcc.i686 into x86_64
> distro, that should be fixed.  gcc is not a multilib package (most of the
> lib* subpackages of gcc are though).

With regards to this bug, are there any plans to make gcc into a multilib package?
Comment 5 Jakub Jelinek 2016-06-02 06:52:51 UTC 
Of course not, why?  Only the (most of) lib* subpackages of gcc are multilib, you only need one compiler when it handles both -m64 and -m32.
Comment 6 Fedora End Of Life 2016-07-19 18:46:25 UTC 
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.