Fedora 18 Will Preview A New Package Manager

[smitty3268]

Epic rant here.

That was awesome.

[Kamikaze]

https://fedoraproject.org/wiki/Featu...BooleansRename

Note that you can continue to use the old names and it will still work.

Cool, thanks for the clarification.

[RahulSundaram]

Wait, what? I'm just starting to get used to some of them without needing to look them up. What prompted this?

https://fedoraproject.org/wiki/Features/SELinuxBooleansRename

Note that you can continue to use the old names and it will still work.

[1c3d0g]

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...

[AdamW]

Yeah, it's a weird beast.

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.

Sorry to be so sarcastic, but seriously. Yeesh.

[Anvil]

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 .

[leif81]

use 'dnf <command>' instead of 'yum <command>'.

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.

[bwat47]

DNF as approved currently is not a replacement for yum. More of a experimental additional one. As for PackageKit GUI, there are several of them. There is gpk-application, kpackagekit etc. The one used in GNOME by default is gpk-application and is getting supplanted by http://worldofgnome.org/gnome-is-rea...an-app-center/ which will be part of upstream GNOME and can be used by any distribution.

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.

[Kamikaze]

- SELinux booleans will be renamed.

Wait, what? I'm just starting to get used to some of them without needing to look them up. What prompted this?

[Kamikaze]

Yeah, it's a weird beast.

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.

Yeah I know one can argue all day about any distro, but I've been willing to use Fedora since F11 and hoping that F-Next will finally be good enough - but each time fail, fail, fail and back to Ubuntu - which always works good enough.
E.g. installing Nvidia (either kmod or akmod) made F17 not boot, or, after a clean install F17 fails to boot after installing like 170MB of updates saying on boot it's waiting for bluetooth, even though I don't got such a device (crazy).
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.

I could be imagining this, but I've found the Fedora releases that the next RHEL will be primarily based upon were usually the most stable for me, though I only ever found one release to be horribly unstable out of the box (F7 I think?). The issue you had with kmod-nvidia sounds like the nouveau incompatibility, where you need to set a kernel param to disable nouveau modesetting and blacklist nouveau from loading. I'm surprised this isn't done automatically yet - considering I stopped using Fedora once I tried out F15 (Arch all the way for my personal laptop!) and I recall having that problem with the release I use at work (F14).