Bug 216980

Interesting. Unlike in bug 216967, this is a case where yum presumably _should_
have installed both versions of the package.

what was the command that pulled in the glibc-devel dep?

(In reply to comment #0)
[...]
> and then, following http://sourceware.org/frysk/build/ install all the following:
> 
> sudo yum install -y antlr jdom junit gcc-java gcc-c++ dejagnu
> libglade-java-devel libvte-java-devel automake xmlto transfig eclipse-ecj
> dogtail sharutils cvs audit-libs-devel binutils-devel
[...]

I've just run across this in a freshly installed RHEL5 (appeared to be 100%
uptodate but I didn't install it originally). yum install glibc-devel fixed the
problem.

Probably there are two identical machines untouched since install if someone
wants to have a look. I can't confirm that until its day time in MN once again
though.

This is really a bug in the package, though -- it says that it requires
glibc-devel and glibc-devel of the "best" arch was installed.  

If gcc is going to default to -m32, then it probably should require the
appropriate glibc-devel.


(In reply to comment #1)
> Interesting. Unlike in bug 216967, this is a case where yum presumably _should_
> have installed both versions of the package.

The difference is that in that case, there was an explicit request for a package
(kernel) to be installed and thus all compat arches get installed.  For a
depsolve, you only need the package which provides the dep.  Adding glibc-devel
to the list of packages being installed here would "workaround" the problem, but
it really seems that the requires for gcc aren't quite right.

Well, the primary broken thing is that on ppc and sparc where we really prefer
32-bit packages rpm shouldn't be preferring 64-bit packages.

As gcc supports both -m32 and -m64 and really can work with either glibc-devel,
depending on what options you use, I'm not really convinced it should require
a particular arch of glibc-devel.

(In reply to comment #6)
> Well, the primary broken thing is that on ppc and sparc where we really prefer
> 32-bit packages rpm shouldn't be preferring 64-bit packages.

This isn't the case though -- we have to prefer 64bit packages, otherwise, we
don't get the right kernel and other things along those lines.

> As gcc supports both -m32 and -m64 and really can work with either glibc-devel,
> depending on what options you use, I'm not really convinced it should require
> a particular arch of glibc-devel.

And similarly, there's no way for yum to "know" unless things are expressed in
the package.

No, the kernel is a special case (and in fact anaconda seems to have been
getting that wrong too, recently).

FYI,

(In reply to comment #5)

> (In reply to comment #1)
> > Interesting. Unlike in bug 216967, this is a case where yum presumably _should_
> > have installed both versions of the package.
> 
> The difference is that in that case, there was an explicit request for a package
> (kernel) to be installed and thus all compat arches get installed.

I mention that a kernel was explicitly installed for completeness, and in the
interest of full disclosure, only (it was to work around another installer bug).
 Installing a specific ppc64 kernel did not lead to the installation of any
other packages.

Per comment #0 and comment #3 glibc-devel was pulled in as part of that yum
command.  BTW, some of the other -devel packages I specified did pull in 32- and
64- bit versions automatically, wierd.

(In reply to comment #9)
> Per comment #0 and comment #3 glibc-devel was pulled in as part of that yum
> command.  BTW, some of the other -devel packages I specified did pull in 32- and
> 64- bit versions automatically, wierd.

If you explicitly specify the package, all available arches will be installed.

Basically, this all looks like it's working as intended and if we don't want to
make gcc depend on a specific arch of glibc-devel, then you either need to a)
explicitly request glibc-devel in this case (which since you're working from
instructions we can update, that's not hard to change) or b) request
glibc-devel.ppc after the fact on ppc.

If that's the position, then this needs clear documentation for end users on how
one is to go about setting up a 32- x 64- environment.

That documentation wouldn't be part of gcc though.

I just ran into this with Fedora 7 plus updates. If nothing else, it seems like
it'd be helpful to have a note in gnu/stubs.h explaining where stubs-32.h and
stubs-64.h come from...

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

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