Oh please no. The yum command is synonymous with Redhat/Fedora. dnf is a terrible name for a common command...almost as terrible as apt-get.use 'dnf <command>' instead of 'yum <command>'.
Put yourself in my shoes. It's two weeks before the release date for Fedora 1. We now need to do all this testing you advise (that's a great idea, by the way, I'll get right on that. Why didn't I think of that before? Testing!)
So, what would you recommend we do? Well, obviously, we need to spin up some ISOs from the current package set. Well, okay, let's do that. (time passes). Okay, we have some ISOs. Let's do all that testing on them. (More time passes, say a day or two).
Okay, now we have this handy list of bugs that we found during testing. All we need to do is get those bugs fixed, and make some more images. Let's go tell the developers about the bugs, and get them fixed! (More time passes, say four days - it's now about a week since we made the test ISOs). Whew, all those bugs are fixed. Let's build some new ISOs and make sure everything's hunky dory before we release this thing.
*spits out pipe*
What the deuce?! Some impertinent developers have gone and *changed things* while we were doing all our testing! How inconvenient! Now all those bugs we found are gone, but all those changes have made things break since we did the testing. How can we possibly deal with this?
I know! Before we release Fedora 2, when it's two weeks before release, and it's time to do all that 'testing' stuff, we could tell the developers they're not allowed to change things any more. We could only let them change things to fix the bugs we find. It would be like the code was...unchangeable. Frozen in time. Ooh! That's a good word! Let's call it a "freeze".
(more time passes)
Well hey, that worked out pretty well. We did all that 'testing' stuff on Fedora 2, and because we didn't let the developers change things while we were doing the testing - that clever 'freeze' thing - we didn't wind up with new bugs showing up in the mean time. But those darn developers, they're never happy. 'What do you expect us to do during those two weeks?', they say. 'Just sit around and twiddle our thumbs?'
Well, yeesh, you just can't please all the people all of the time. But let's try. For Fedora 3, what we could do is have a separate place where developers could work on things while the main place we keep all the packages we're building the release from is 'frozen'. Let's call this separate place, ooh, a 'repository'. That way the developers can be happy and keep working, but what they're doing doesn't screw with our testing and we don't get lots of changes in the images we're building! Gee, what a clever idea.
So now it's Fedora 3 release day, and we have these well-tested images right _here_, and all these updates the developers have been working on over _here_, in this 'side repository'. We also, believe it or not, have a rather sophisticated process in place for testing these updates, and there's no reason we can't run that process while the freeze is in place. Actually, we do. So we have a big pile of updates which have been tested as updates always are, but which didn't get into the release because of this crazy 'freeze' idea we invented. So what do we do with them? We release the bloody things.
Congratulations, you are now up to date with where the entire bleeding software industry was in, oh, 1983 or so.
tl;dr summary: there is a perfectly good reason there are a lot of updates on the day of a Fedora release. It's because of a process that's been standard in the software industry for bleeding decades. It is not, shockingly enough, because a major distribution community backed by a billion-dollar software company is staffed entirely by drooling imbeciles. I realize it's hard to accept, but believe it or not, most of us actually know what the fuck we're doing most of the time.
Sorry to be so sarcastic, but seriously. Yeesh.
Well fucking said. Some people have their heads up their asses and really have no idea what it takes to finalize a successful release.
Having said that, I'm glad the GUI for YUM is in for a change. That thing froze so many times on me, I lost count - forcing me back to the command line to do any useful work. Maybe installing/removing packages should be left for YUM (the command line) only? Something to think about...
I have used RHEL and Fedora a bit and then I got Debian and Ubuntu to my hands. That's where I understood that I like debian package management far more than yum/rpm. RPM itself is dumb and not meant to be used on daily basis. It's like dpkg in Debian and surely needs front end. That's where Fedora and RHEL hit their wall. Yum suxx. When compared to others.
1) Yum is slow. No, really it is. Does not stands comparison.
2) Yum is a memory hog. You see, on virtual machine with 128Mb RAM (which is more than enough to boot it and run networked services) yum would eventually cause OOM when installing packages with a lot of dependencies.
3) It's awkward and uses awkward data formats for repos. At the end they fugured this causes such a horrible performance that now they gone as far as to download pre-built SQLite databases. Which is a really strange way of doing things.
So yum suxx. Absolutely. And it looks that for some reason they failed to completely trash it to garbage bin and rather prefer to half-fix it. However the only proper way to "fix" this garbage is to completely trash it, give a boot to python script kiddies and rewrite it using C/C++ and adequate programmers, so it would be fast, do not eat hundred megz of RAM and will not be plagued by bugs. Somethings that other decent distros did ages ago. Most notably, debian based, suse-based, etc.
As for me I would never consider Fedora again and will avoid RHEL as much as possible unless they completely reconsider their shitty package management.
Last edited by 0xBADCODE; 06-19-2012 at 04:34 AM.
i thought ZIF was going to replace yum. http://people.freedesktop.org/~hughsient/zif/ It is mention on the DNF FAQ, but not really explained.
The idea of a shared dependency solver across distros is nice. I wonder if it can help bring advanced features like differentiating between depends, recommend and suggests as used in debian.