If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
I haven't used the other two packagekit gui's, but a crappy gui isn't the only issue with packagekit. I've ALWAYS had annoying lockups and bugs when using packagekit to install software (and fedora's gui updater, I'm not sure if that is packagekit or not but it has similar issues)
using yum never gives me any issues, but packagekit is a buggy mess in my experience. Good riddance when that finally gets replaced. Its what often gives fedora's package management a bad rap. I've seen people say stuff like "I tried fedora but RPM is horrible!". Problem isn't rpm and yum, they are solid they probably used packagekit and ran away from that buggy abomination /rant.
i dont see why so many people use " GUI's " all the time in Linux. use Microsoft windows if you " Need " GUI all the time. as for packagekit, no one is forced to use it if it doesnt work Nicely for you. iv'e even seen people saying how bad Software center/Synaptic is. but lets not go offtopic. there is nothing wrong with RPM IMO. read the advantages of RPM compared to .DEB .
But the #1 feature Fedora needs is better testing Fedora itself and treating it (more) seriously, I mean, after F17 was released I installed it the next day and that same day got like 150MB of updates. Same for F16 btw.
It means Fedora's understanding of "final release" is one of the loosest (and lousiest) in the world.
Again, #1 needed Fedora feature is better testing its .iso/stack/updates, if the folks from Fedora (i.e. Red Hat) can't - then ask Canonical for a guide, or whatever.
Hi. I am the Fedora QA team leader.
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.
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.
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.
You propose having two commands on the system, both called "yum"?
While the new command remains experimental, it will have a new name. When it REPLACES yum (assuming that it works out...), it will be renamed TO 'yum'.