Red Hat Bugzilla – Bug 597080
Too Many packages labeled with FC12
Last modified: 2014-03-16 23:23:46 EDT
During my upgrade with yum from fc12 to 13 I had a problem with nss-softokn on one of my machines. It was nothing serious and I was able to overcome it. It turns out that on that the version of all nss packages on Fedora 12 was 3.12.4-19 of all of the nss. So I had to manually call
yum downgrade nss* and all was well.
Then I ran "rpm -qa | grep fc12" The output showed almost 500 packages labeled as belonging to to fedora 12 repository. And when I pointed my browser at the repository what did I find.... A gazillion packages labeled *.fc12*
How am I supposed to know if I made a complete and successful transition. And please don't even tell me Fedora only recommends upgrading from the DVD. I use multiple repositories.
Doesn't anybody over there think that packages released for Fedora 13 should be labeled fc13.
And if a package can't be built against the fc13 build environment then that is a show stopper; at least for that that app? And if the goal was to get the full set of apps out then shouldn't the thinking be... we couldn't build packageX so fcX is not ready?
Please forgive my tone. This is not a troll. I really am just asking questions. I really am highly appreciative the amount of tremendous, quality and care that goes into each and every Fedora release.
Thanks For any response you may provide.
As discussed on the mailing list, we don't rebuild every single package between releases. It is a waste of resources; our build and test resources, our storage resources, our mirror resources, and client resources such as bandwidth and cpu time. We only rebuild when it is deemed necessary, and we rely upon inheritance for the packages we don't require a rebuild for.
That said, there are a few name-version-release issues where an F12 update is newer than the F13 release. This shouldn't happen, but currently it's up to the maintainer to ensure that. However we are building up an automated testing environment that will detect these errors and call attention to them before they get to a user's system.
In short, what you experienced was one part bug, many parts design. The bugs are being addressed, and the design will stay.
I understand what's been said, but again, I need to ask. If I have packages in the fc13 repository labeled as belonging to fc12:
1) how is one to ensure that when they upgrade they get all the packages that belong to fc13?
2) How is one to ensure that some obscure symbol in some supporting library does not get altered in the recompile which brings the whole house of cards crashing down? It has been my experience that the maintainer's "works for me" often does not work for an awful lot of people.
3) Has Fedora gotten too big for itself.
Thanks for your response
(In reply to comment #2)
> I understand what's been said, but again, I need to ask. If I have packages in
> the fc13 repository labeled as belonging to fc12:
> 1) how is one to ensure that when they upgrade they get all the packages that
> belong to fc13?
Generally you trust us to put the right packages in the repositories. However you can verify by using 'koji list-tagged --latest dist-f13' and 'koji list-tagged --latest dist-f13-updates'. You can even check dist-f13-updates-testing if you have that enabled.
> 2) How is one to ensure that some obscure symbol in some supporting library
> does not get altered in the recompile which brings the whole house of cards
> crashing down? It has been my experience that the maintainer's "works for me"
> often does not work for an awful lot of people.
This is something that can happen with a non-inherited build too, so it's not just a concern with F12 build packages in F13. Basically you have to rely upon our QA system, which is largely user driven. Maintainers respond to karma feedback and bugs from users in order to fix things.
> 3) Has Fedora gotten too big for itself.
Fedora is certainly going through growing pains, but they aren't insurmountable. Because we're a volunteer project we rely a lot on our users and contributors to make things happen. We are working on infrastructure to help them, but in the end it is contributor driven.
> Thanks for your response