Description of problem: When issuing a "yum install gcc" get the following dependency error: Error: Package: glibc-2.16-24.fc18.i686 (fedora) Requires: glibc-common = 2.16-24.fc18 Installed: glibc-common-2.16-28.fc18.x86_64 (@updates-testing) glibc-common = 2.16-28.fc18 Available: glibc-common-2.16-24.fc18.x86_64 (fedora) glibc-common = 2.16-24.fc18 Version-Release number of selected component (if applicable): Linux localhost.localdomain 3.6.11-3.fc18.x86_64 #1 SMP Mon Dec 17 21:35:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Current lxde Live CD from fedoraproject.org. Downloaded 12/23/2012. After installing updates. How reproducible: by running yum install gcc Steps to Reproduce: 1. Install Fedora 18 LXDE Live from Desktop link 2. run "yum update" 3. reboot 4. run "yum install gcc" Actual results: Get a dependency error from yum. Expected results: Expect versions to be correct for dependency installation. Additional info: Fresh install of Fedora 18 LXDE. This is not the same as bug 820747 since I'm installing the same platform version (x86_64) and I'm using whatever defaults F18 uses for gcc and its dependencies in yum database (IOW, I don't control the dependencies and the versions it is looking for).
Getting same problem -- yum install glibc.i686 Error: Package: glibc-2.16-24.fc18.i686 (fedora) Requires: glibc-common = 2.16-24.fc18 Installed: glibc-common-2.16-28.fc18.x86_64 (@updates-testing) glibc-common = 2.16-28.fc18 Available: glibc-common-2.16-24.fc18.x86_64 (fedora) glibc-common = 2.16-24.fc18 WINE install fails for this reason.
Run yum with --enablerepo=updates-testing
(In reply to comment #2) > Run yum with --enablerepo=updates-testing Thanks, that works.
(In reply to comment #1) > Getting same problem -- > > yum install glibc.i686 > > Error: Package: glibc-2.16-24.fc18.i686 (fedora) > Requires: glibc-common = 2.16-24.fc18 > Installed: glibc-common-2.16-28.fc18.x86_64 (@updates-testing) > glibc-common = 2.16-28.fc18 > Available: glibc-common-2.16-24.fc18.x86_64 (fedora) > glibc-common = 2.16-24.fc18 > > > WINE install fails for this reason. Your issue is a little different, you are trying to install a 32 bit package on a 64 bit system. In my issue, all I'm doing is issuing a "yum install gcc".
I love how it just gets dismissed out of hand by the person assigned. I had to implement a work around to install gcc. That's not normal. Something is wrong somewhere with the version or how the yum database is setup. I'm able to replicate this error at will so it's an issue.
What workaround did you use? Didn't --enablerepo=updates-testing work for you? updates-testing has been disabled for F-18: http://lists.fedoraproject.org/pipermail/devel/2012-December/175593.html
(In reply to comment #8) > What workaround did you use? Didn't --enablerepo=updates-testing work for > you? updates-testing has been disabled for F-18: > > http://lists.fedoraproject.org/pipermail/devel/2012-December/175593.html Yes it did. The point of the bug report is to alert whomever that yum is still pointing to the wrong one or whatever. Anyone who downloads the current ISO image and does a default install and then installs updates via "yum update" and then decides to install gcc (and perhaps other packages, IDK) will get a dependency error. I got the error and then had to stop what I was doing to track down what was happening and how to fix it. Closing it by saying it is not a bug is really silly. Is this the behavior that the Fedora project wants to have, broken dependencies due to the wrong repository being referenced? If not, then it's a bug that needs to be addressed.
(In reply to comment #9) > > http://lists.fedoraproject.org/pipermail/devel/2012-December/175593.html > > Yes it did. The point of the bug report is to alert whomever that yum is > still pointing to the wrong one or whatever. Anyone who downloads the > current ISO image and does a default install and then installs updates via > "yum update" and then decides to install gcc (and perhaps other packages, > IDK) will get a dependency error. > > I got the error and then had to stop what I was doing to track down what was > happening and how to fix it. That's how beta releases are. You can't install a beta and expect to never have a problem. While I agree that this is somewhat cumbersome, I don't think a bug report is the place to discuss this because it has more to do with release policies than any specific package. You might want to start a thread on the fedora developers mailing list (devel.org) > Closing it by saying it is not a bug is really silly. Is this the behavior > that the Fedora project wants to have, broken dependencies due to the wrong > repository being referenced? If not, then it's a bug that needs to be > addressed. Like the mailing list thread I pointed to mentioned, it is 'expected' behaviour in the sense that it's a breakage that is expected and developers and testers need to work around it. Anyway, I don't speak for the fedora project as a whole, so a discussion on the devel list is more appropriate. I'm going to reassign this to fedora-release since this has nothing to do with glibc.
(In reply to comment #10) > (In reply to comment #9) > > > http://lists.fedoraproject.org/pipermail/devel/2012-December/175593.html > > > > Yes it did. The point of the bug report is to alert whomever that yum is > > still pointing to the wrong one or whatever. Anyone who downloads the > > current ISO image and does a default install and then installs updates via > > "yum update" and then decides to install gcc (and perhaps other packages, > > IDK) will get a dependency error. > > > > I got the error and then had to stop what I was doing to track down what was > > happening and how to fix it. > > That's how beta releases are. You can't install a beta and expect to never > have a problem. While I agree that this is somewhat cumbersome, I don't > think a bug report is the place to discuss this because it has more to do > with release policies than any specific package. You might want to start a > thread on the fedora developers mailing list (devel.org) > > > Closing it by saying it is not a bug is really silly. Is this the behavior > > that the Fedora project wants to have, broken dependencies due to the wrong > > repository being referenced? If not, then it's a bug that needs to be > > addressed. > > Like the mailing list thread I pointed to mentioned, it is 'expected' > behaviour in the sense that it's a breakage that is expected and developers > and testers need to work around it. Anyway, I don't speak for the fedora > project as a whole, so a discussion on the devel list is more appropriate. > > I'm going to reassign this to fedora-release since this has nothing to do > with glibc. OK. I do understand how beta software works, I use it and I also use alpha software, I'm not complaining about the fact that there was a problem. Breakages are expected. I just thought that the project would _want_ to know that this is happening. If no one ever put in a bug report for this how does it ever get addressed? Updates-testing is disabled for F18 yet the yum database (I'm guessing here) doesn't know that. Are you saying that it automagically gets fixed with the next or final release of F18? I only chose glibc because that's what I was doing-I fully expected it to go to another area. I'm assuming that the glibc maintainers also update the RPM database but that may not be a good assumption. BTW, if I don't run a "yum update" after a fresh install, and instead issue a "yum install gcc" gcc (and glibc) installs just fine without a dependency error and a subsequent yum update runs just fine. The problem only occurs if one first updates, _then_ tries to install glibc. That's pretty specific if you ask me. Anyways, I don't usually put bug fixes in but I wanted to do my part and let it be known. Otherwise, I'd just google for the workaround and move on. Anyways, thanks for the response.
*** Bug 891574 has been marked as a duplicate of this bug. ***
Jens, please read comment 10 and comment 11, which explain why this is not a bug in glibc (similar argument for gcc) and why fedora-release was selected as the component. The broken dependencies happened because there was a change to the repo files during beta to disable the updates-testing repo by default, which led to broken dependencies. Enabling updates-testing and then doing the updates works, but the reporter wants a longer term solution to this where such a problem does not happen and neither gcc nor glibc can provide that. If nothing can be done about this, then it should be closed as CANTFIX.
The testing repo gets turned off between Beta and Final release, and causes a small window where this kind of problem can occur I don't see any simple way of avoiding it. Fedora is not really supported before Final release so one should expect minor problems and surprises like this even after Beta. Users who are uncomfortable with that should wait until after Final release before running latest Fedora. :) Anyway moving this back to fedora-release but I am not really sure anything can be done short of making this kind of issue a blocker to turning off updates-testing, which would further delay releases for what is really something (annoying but) technically trivial to workaround. BTW a safer workaround would be to run "yum distro-sync".
There really is nothing we can do here. when you move from pre-release to final the user needs to do a "yum distro-sync" to ensure their system is in a good consistent state.