Last month Eric S. Raymond made a public announcement on the Fedora developer’s list that he was giving up on Fedora Core and that from now on Ubuntu is his distribution of choice. Actually it was more of a rant than an announcement. ESR’s scatter shot attack on Fedora was wrong in more ways than I care to comment about here. Chromatic did a nice job of attacking the rant on several key points. He also pointed out quite correctly that ESR’s accomplishments as an Open Source activist didn’t make his changing distributions newsworthy.
The reason I’m not simply ignoring ESR is that he did point out a real problem with Fedora Core, one which I also noted in my review of Fedora Core 5 last year. When upgrading a system with yum or pup I ended up with upgrades that couldn’t be run because of dependency issues. ESR ran into a more serious example of the same problem: an automated upgrade breaking significant parts of his system due to similar dependency issues. While the Fedora team at Red Hat has generally been good about fixing such issues within a few days it’s really disappointing that they are still happening and, in fact, becoming more serious with time.
ESR blames rpm, which he believes to be buggy, and yum, which he believes to be overly complex. He is totally wrong on both counts. rpm is a stable, mature, and excellent package management system used by more Linux distributions than any other. yum is no more complex or difficult to use than Debian’s apt and has very similar functionality. Nope, the problem isn’t in the code. That’s the disturbing part of the story, the real piece of news, that everyone seems to be ignoring.
Right now I have something like nine Linux distributions in my office/lab. Aside from Fedora none of them, as in zero, has had a serious problem with their package repositories or their automated update software in their current releases. There is no excuse, absolutely none, for the sort of problems that Fedora Core has experienced with package management.
So… am I giving up on Fedora like ESR? Nope. I’ll give Fedora Core 7 a good long look. The Fedora Project and Red Hat Linux before it have had problems in the past. They’ve always managed to correct their issues and bring out a first class distribution. What’s different this time is that they can’t solve the problem by issuing a new patch or bugfix. The code isn’t broken. The problem is insufficient testing and just plain sloppy repository management. What Fedora’s repository managers are really lacking is attention to detail. It’s a human issue and those issues are always the hardest to fix.
I'd say it's "no testing" rather than "insufficient testing". Not long before Fedora 7 test one, I went through an upgrade from Core 6 to rawhide, and what it brings to me is killing X Window in the middle of upgrade (along with yum), leaving rpm database broken with hundreds of duplicate package record. In my 10 years' history no other distro has even done that.
FWIW, I has similar experiences with old versions of SuSE, which led me to losing trust in RPM-based package management. Still, things have improved since. Grab a copy of Fedora 7 before echoing ESR in a second-hand(ish) fashion. :-)
I was on the verge of moving away from Fedora when I read ESR's rant. It drove me to Ubuntu. I've been running it for about a month now and a) its really good, b) its way more stable and c) there aren't 1/10th of the updates that FC had.
The last point is a double edged sword. Ubuntu Edgy still uses KDE 3.5.5, whereas I know that FC6 is running 3.5.6. I know I can do a manual upgrade, but I'd like to see it come through the Ubuntu repository as an official upgrade. Maybe there is a reason that it isn't, I don't know.
People always told me FC was a bleeding edge product and now that I run Ubuntu, I see that.
I could say more, but I'll stop there.
"...c) there aren't 1/10th of the updates that FC had."
This will always be the case with Fedora Core. The Fedora project is more or less a development sandbox for Red Hat Enterprise Linux, and as such is on a VERY rapid development cycle compared to most other distributions. This also means that Fedora will have nearly all of the latest and greatest versions available, and publish updates for them as soon as they are made available.
I don't know about you, but a little buggyness is a price that I will pay for being on the front line of the bleeding-edge software releases. Especially being that I am a Systems Administrator of Red Hat Enterprise Linux servers in a "mission critical" environment.
In addition to that, I learned long ago that when upgrading OS version, it's ALWAYS better to do a full ground-up rebuild for stability and filesystem cleanliness.
Well I think ESR is, at least partly, right with his opinion on rpm and yum. Lately I played around with CentOS 5 beta (recompiled RH EL 5 beta2) because I might deploy RH EL 5 servers. Last former contact with the rpm world has been in 2003 for me. Since then I've mostly deployed solutions based on Debian. What I noticed while installing CentOS 5 is that the dependency calculation process still takes a _very_ long time compared to Debian installations. Even yum is still very, very slow compared to the apt tools ported as apt-rpm for rpm based systems. Ok that's nothing new, it's even a widely known fact that the rpmdb binding make apt-rpm slow. Partly this problem might be related to the fact that RH uses file based dependecies which clutter the rpmdb and make dependency calculation slower. BUT that's not an excuse that third party tools like apt-rpm are faster then yum.
I don't know what's the state of afairs is on SuSE or Mandriva based systems but I doubt that they're off much better.
Conclusion: rpm is aging and requirements for packaged software are higher then ten years ago and rpm hasn't evolved that much over the time. I remember that their has been some rumours in the press that some people would like to start development of rpm again with support of all major rpm based distribution to get a unified rpm again.
where is the story? All I see are comments on this page. Firefox 2.0.0.2 - Ubuntu Edgy
There's no story here. Did you pull this op-ed piece?
You want to run rawhide .... ummmm, rawhide is not designed to be run ... if it is even consistent that is an accomplishment.
Please, at least let them freeze the packages and test them together in a Test1 or Test2 environment.
Fedora can't be that bad.
It has over 2 millions users:
http://fedoraproject.org/wiki/Statistics
However you have a point on the repo. thing.
The Fedora Extras/Core merge and new infra.
in Fedora 7 will hopefully fix this.
"ESR ran into a more serious example of the same problem: an automated upgrade breaking significant parts of his system due to similar dependency issues."
Sorry no. This is completely wrong. ESR was running rawhide aka Fedora development branch and he rm'ed a important critical library which ruined his system.
If you want to see RPM work very well try OpenSUSE 10.2. As the author said, RPM and YUM are not the problem, they are good tools at the base of a package management system and work great if used properly.
We've depended on Linux since 1999 when all of our systems and R&D were converted to Linux and have been very happy with it overall. During the years we've played around with most of the major distros and seen different approaches to package management (including the ones on Digital Unix and Solaris). RPM is clearly capable of doing the job and doing it well.
However, like all technologies, you can use it poorly and make it look bad. I don't think you can say RPM/YUM are bad simply because Fedora has been lazy about their testing and don't have tools to reconcile the dependency issues. RPM's job is to tell you that you have a dependency problem and what is needed, the package system wrapped around that should find you the right package based on that information. Put a good wrapper on it and it works wonderfully.
The approach used by YAST is just one example of how easily many repositories can be identified and dependencies resolved across all of them to make installations and upgrades easy and painless.
Cluck Cluck ... is this a day at the hen house? Lets all puff out our chests, fluff ourselves bigger and shake our tails around a bit while we scratch the ground! HA!
I have to agree with Linville79 and others who say "why do an upgrade when one has the advantage of a fresh install". Is there something called best practices that would let one segregate user data from the OS on separate partitions?
Yum is great compared to uptodate and it sure beats what this other guy I know does. He's a hard core Slackware guy, but he still goes to the sites for individual pieces, downloads the source tarball, checks things out before he compiles it and tries to add it to the system. He had to admin a RH Enterprise box for a while, went out and got updates instead of using RedHat network.
Packaging system not fast enough, what do you think multiple windows and workspaces are for? Kick it off, let it run, and do something else; unless your into watching grass grow, paint dry or rust form.
Interesting points that poeple have made but I dont see any problem. When has Fedora every recommended 'in-place upgrades' via yum (http://fedoraproject.org/wiki/YumUpgradeFaq?highlight=%28upgrade%29%7C%28yum%29). If I read correctly they say that it is possible but it is not recommended. So you are doing something which the designers of the software say that it is not recommeneded. If I read correctly they are saying they are going to try and address this with Fedora 7.
Abel Cheung says that upgrading his system to use rawhide killed something. Forgive me if I am wrong but isnt rawhide unstable and has the ability to kill your system (and eat babies as well). So upgrading into an unstable and in heavily developed (this is where the active development of Fedora 7), is a bit harsh to blame Fedora for doing that.
Sven says that upgrading takes ages with rpm/yum. It maybe the fact that it is slow, but since updates arent really that important fact for speed why is it such a major problem. I am happy that the update process works and usually behind the scenes means that it is of no concern to me that it might take 10 minutes compared to 5. As long as it works and everything is OK I am happy. As to the old age deb/apt is better than rpm/yum well there is a lot said about this and so no use going down that path. If you are interested then please google for it, each side has good/bad points.
I gave up on Fedora Core last fall when an upgrade (my third) totally borked my system. I had to go back two kernels before it would boot. To be honest I think it was a disagreement between ReiserFS and SELinux. I had used Fedora Cores 3, 4 and 5. I have other issues as well.
* Schizophrenic repositories: Don't mix ATrpms and Livna with anything else (unless you're very very careful) or you'll get a lot of practice installing Fedora Core. Come to think of it that is completely nuts. I don't think any other distribution has three sets of incompatible repositories.
* Did not (maybe it does now) fully support KDE. I found out after I switched to PCLinuxOS what a full installation of KDE is like (I was kind of ticked about that too).
* Installation of proprietary codecs required detailed instructions from sites dedicated to "fleshing" Fedora Core out for media content. Not the fault of the development team but of our mildly Fascist greed intoxicated government by corporation economic system. Well maybe "mildly" was putting it a little mildly.
One of the reasons I kicked Windows XP the hell out of my life was because I was tired of surprises. Especially nasty ones. I need a system that is consistent and stable. It helps that most distributions of GNU/Linux are technically superior, incredibly configurable and a hell of a lot of fun. I'm very happy with PCLinuxOS and when the new version comes out (any day now) I will be installing it on 6 systems, two of them new to GNU/Linux.
I used mandrake/mandriva for quite some time (since 2000), and my home server was mandrake/mandriva till this Spring Festival. Some time earlier, at the urpmi --auto-select stage, a newer courier-* package was installed but its dependency failed. Then, I couldn't upgrade it, or even remove it to reinstall courier-* packages. The rpmdb had problem. I finally gave up the rpm and install debian on my home server.
Urpmi works fine in general but
1. It's slow to urpmi.update, the download is too large and time consuming even with 2M line. So I have to set up a local mirror
2. It's slow when rebuilding dependency database
3. It breaks rpm database now and I have to handle problems by hand.
I think the problem is not on urpmi itself, but from the bottom - rpm.
Installing new system from ground every time just makes no sense. The package system should provide smooth upgrade path, except for the case that upgrading from libc5 to libc6.
The problem is insufficient testing and just plain sloppy repository management. What Fedora's repository managers are really lacking is attention to detail.
Can you please back up such a theory with at least a few detailed examples of broken dependencies? Feel free to contact me privately (mschwendt AT fedoraproject DOT org). I'm really interested in examining such reports, because most of the time when I meet somebody with dependency problems, the reason are non-Fedora packages, which are incompatible. Not seldomly they are so incompatible, they even make a full upgrade of the distribution impossible. Every Linux distribution can be broken in the same way.
As one of the people who maintain the Fedora Extras repositories for quite some time, I'd like to point out that we are aware of all broken dependencies because a tool searches for them, reports them to the package maintainers, mails a summary to a public list, and the same tool can also be used to keep Fedora Extras free of broken dependencies. As a side-effect, the tool also examines Core for broken dependencies.
What remains to be done is to complete the merger of Core and Extras. The Core and Extras repositories are still separate and maintained by separate people. This means that hot-fix updates released for Core can break dependencies in Extras until Extras is updated accordingly. Fortunately, the Extras packagers usually are very quick in updating their packages. Over the past months, it has mostly been Firefox updates which have broken a very few packages that depend on a specific version of Firefox for a day or so. And, of course, new kernel versions breaking two kernel module packages and a few more in a well-known 3rd party repository. I hope you agree that kernel and Firefox updates are so important, that Core packagers cannot wait with them until a very few optional add-on packages (also by a 3rd party) are updated, too.
To make it clear, I refer to Fedora 6 and Fedora 5. The Fedora 7 Development bleeding-edge repository is a completely different story. Still, there are public broken dependency reports for it, too.
I've recently switched from Fedora Core to Kubuntu. Fedora has problems, but ESR didn't hit upon any of them in his rant. The problems he encountered were of his own making.
If you stick to Fedora's repositories, then the distribution is 100% safe and effective. The problem is you can't stick with Fedora's repositories and still have a useful system. I had to add ATrpms in order to get MythTV, and I had to add Livna to get media playback (the latter, though, is not Fedora's fault). I had to download the accelerated video driver from nVidia's site because Fedora won't include it in its own repositories. It took me a full day to get wireless to work, with packages I had to download and assemble from multiple sources, for 10 minutes (after which it stopped working permanently).
Fedora's problem is indeed repository management, but it's not an issue of sloppiness. It's an issue of being woefully incomplete.
Kubuntu's repositories are complete, and the distribution has a high degree of finish. My laptop wireless worked in under 10 minutes, the nVidia driver came through the official repositories (though it required two manual tweaks; for shame!), MythTV was a trivial install (as were media players with full codec compatibility), and most everything on my Kubuntu desktop is configurable via well organized user interfaces.
What kind of a freaking *MORON* does a upgrade when moving to a newer vsesion of an OS reather than backing up their files and do a *CLEAN INSTALL OF SAID OS* and then restore from their backups? I'll tell you who. A bunch of know-nothing lame-a**ed PC GAMERS that's who.
Having lived with pup, pirut, yum, yumex and rpm, since I started in linux two years ago, and having watched my peers with their ubuntu package managers, I have to agree to some extent with ESR and the current author.
Raymond pointed out one a serious problem. the installer programs I mentioned all use dynamic libraries, libraries (known as dlls elsewhere) which are shared and which can be overwritten. That includes the sqllight program. So, a corruption in a library or in sqllight halts all future package updates.
A second problem that I feel is current in every package manager, is that by default, there is no rollback facility that is built-in. For example, I may install a x windows update, only to find it is broken for my motherboard, and I need to roll back. I am not able to do so, automatically.
Third problem is that I would like to put in a safety delay for all updates. By that I mean that my running of yum, pup, pirut, would only take updates older than xx days, where I establish xx. Others may want instant gratification, or problem, but I want to read about the problem, if there is one and not install a faulty program. It this regard, I am willing to wait to not be on the bleeding edge.
What is required.
a) A static link, for rpm and pup. That would make rpm and pup independent of libraries.
b) With respect to package updaters such as yumex, determine if there is a stand alone isam set of routines can be used and the use of sqllite removed. (Noting wrong with sqllite, except that it is shared).
c) Introduce a package roll back facility, based on a ring of versions. Thus, I may decide to keep three update runs, before wrap around occurs. and be able to go back three update times.
d) Allow me to set a threshhold on file newness, as I indicated above.
Abel Cheung: rawhide is alpha code. If you install Rawhide you are supposed to be doing the preliminary testing. Fedora has it's obvious faults but I can't fault them for issues in alpha code.
Roy Schestowitz: I'm not quoting ESR second hand. I've had significant issues myself with FC6 which is why I'm not running it now. SuSE, Red Hat Linux, Caldera OpenLinux, et al.... about eight years ago all had issues with rpm. We used to call it "rpm hell". SuSE hasn't had issues in years. Sorry, but you are defending the indefensible.
Linville79: I agree that Fedora is the development sandbox for RHEL but Red Hat doesn't portray it that way to the Linux community. They pitch Core as a stable community-supported distro, the successor to the old Red Hat Linux. As such we should expect more. If they said RHEL Development instead I'd have no complaint. In other words, they somewhat misrepresent the product. Further, Fedora's release schedule (once every six months) is exactly the same as Ubuntu's and yet Ubuntu remains stable and reliable. You too are defending the indefensible.
Sven: I don't disagree with your comments about rpm. yum is slow because rpm is slow. My point about them had nothing to do with speed. It had to do with the fact that they aren't broken and can be very reliable if repositories are managed properly. Mandriva uses urpmi rather than yum, BTW. Mandriva is probably the poster child for repository management done right. They have an excellent, stable, user friendly distro. I tend to prefer Vector and Ubuntu, but those are just preferences.
Pekka: Windows must be the best. I mean... think about it. It has hundreds of millions of users. A lot of people stick with Fedora because that's what they are used to or because they have to support RHEL at work and Fedora is similar to RHEL with newer code. Repo issues are serious. If they were solved I'd go back to calling Fedora Core one of the best Linux distros out there. Right now I just can't.
jef: Please show me where ESR said he was running Rawhide and not FC6. FWIW, I don't run Rawhide, as in not ever, and I still ran into serious repository problems with FC5 breaking apps here and there that were important to me for days at a time. FC6 is several orders of magnitude worse than FC5 despite having essentially the same code. I wouldn't have written this if I didn't have first hand experience with it.
Great comments all around... I'll do a few more responses in a little while.
A few more reply comments:
James: I checked the first link and it takes me directly to ESR's original post. I'm running the same version of Firefox you are so I don't know what to tell you.
offline: Do you disparage anyone who disagrees with you? up2date was a front end to yum and has been replaced by pup. up2date wasn't anything separate from yum, just a GUI for it.
Regarding Slackware: lack of sane package management is the downfall of what otherwise would be a fine distribution. The good folks at Tuukani Linux went ahead and added what was missing with two tools: slapt-get (Slackware apt) and gslapt (graphical slapt). They work well. Vector Linux uses Tuukani packages and they have had no repository problems whatsoever since the release of version 5.8 despite using relatively new, feature-poor code.
If anything you've made my point for me by raising the issue of Slack.
Wang Jian: I've had zero problems with Mandriva 2007 or 2006. Maybe I've just been unusually lucky.
Mr. Schwendt deserves a separate and detailed reply which I'll post in the next day or so.
Having installed hundreds (no exaggeration) of distros over the years, I note that only two having given me major problems - Mandriva and Fedora, but mainly Fedora (I may be wrong but wasnt Mandriva originally based on Red Hat?). I am talking trashed partitions, corrupt boot sector, and generally making my PC completely unuseable. I tried installing Fedora Core 7 Test 2 a few days ago, and amazingly it would not recognise my nForce 4 PATA connected CD-ROM so I couldnt even install it. Hows that for a 2007 distro based on more or less the latest kernel. Ubuntu, Debian, Mandriva, PCLOS etc have no problems with this, and the nForce4 hardware is hardly new.
It seems to me that Fedora is one of the least reliable and competantly maintained distros around. I am always surprised as to how popular it is, and can only assume it is something to do with its country of origin.
Hello Caitlyn Martin,
good opignon, I agree with you. Btw, it will be only Fedora, no Fedora core/extras :)
Precisely what I've been complaining about on numerous sites over the last few months.
Insufficient money and manpower for testing and quality control.
While you may not see package update problems on some other distros, they do exist. Look at Novell's last couple of releases - a package bug made the update system useless until a patch was released.
Look at Kubuntu. They released an installer that wouldn't let you exit the change mount points screen. That means the INSTALL PROCESS WAS NEVER TESTED AT ALL! Excuse me?
ALL the Linux distros are having serious problems with quality control and testing - and not just the one- and two-man distros. PCLinuxOS gets rave reviews from everybody, despite being a small distro, for making sure things "just work".
But most distros appear to be overly concerned with installing "eye candy" like Compiz and Beryl rather than taking the time and effort to insure that the installation, system upgrade and package update processes are rock solid. And those three areas are where Linux newbies get bitten immediately they try Linux (that and odd hardware driver support - particularly in wireless).
In particular, wireless detection and configuration needs to be FIXED and AUTOMATED. EVERYBODY is using wireless and laptops these days. This needs to "just work".
Instead, Kubuntu 6.10 was released with the Wireless Assistant, which is a POS that doesn't work well with WEP security.
This kind of thing is not helping Linux adoption by new users.
As for upgrades, while it may be "best practices" to do a clean install of a new release rather than upgrade - and this is true in Windows as well, despite some people claiming otherwise - the fact remains that if you're going to offer an upgrade mechanism, IT SHOULD WORK. Otherwise, DON'T OFFER IT.
It's that simple.
Granted, there will always be somebody with such an oddball constructed system that nothing will save it during an upgrade - but in that case, offer a downgrade option (given the disk space) like Windows does and put the system back where it was automatically.
On Kubuntu, I was offered an upgrade of kernel headers recently. I said, Okay, do it. Then it tells me it can't because it will break something. Fine - why not find that out BEFORE offering me the upgrade?
It's simply a matter of design. The problem with a lot of OSS is that the intent is to get SOMETHING working, then throw it out there and hope somebody improves it. That works fine for people who don't mind that. It does NOT work for end users who just want Linux to "work". I think the line is being blurred for many distros between what is "stable and feature-complete" and what is "under development". In the effort to compete for mindshare with other distros and Windows, distros are becoming as bad as Windows in terms of quality and reliability and security. This needs to stop or Linux will get a crappy reputation as well.
The distros need to stop the "release often" tactic and start releasing once a year, taking the extra six months to make sure the release is SOLID.
What's the hurry? Servers don't need bleeding edge, new users don't need bleeding edge, and MOST users don't need bleeding edge. Is the whole Linux community being held hostage to the 5% of te community (developers) who need bleeding edge?
up2date never has been a front-end for Yum and never has used Yum. It contains its own back-end for Yum and AptRPM repository metadata, but that's all. It has been the package tool for Red Hat Network always.
[...]
It is somewhat unfortunate how separate issues are being mixed and make it difficult to understand the primary complaint.
I partly blame the terminology for that. It doesn't do anyone any good if too many things are thrown into the mix: bugs, testing, QA, packaging, repository management, dependency issues, bleeding-edge, and so on.
Broken dependencies
These are very interesting. This is the scenario ESR referred to without showing what he had seen (and without explaining why he deleted a system library forcibly). Anyway, broken dependencies are known as: Packages in the repository which cannot be installed since Yum refuses to install them, because they require something which doesn't seem to be available. Often it is not obvious to the user where the problem is.
For example, Yum's default transaction check failure report is not verbose enough in explaining why a library, which is present on the file system, is reported as missing when trying to install updates. It makes the user think "WTF?". Of course! Most users cannot know (and should not need to know!) that some poorly prepared package tries to install a major version upgrade, which not just would install something new but also would take away something that other packages in the distribution need. In other words, the package to be installed is incompatible and breaks other packages' requirements.
This is the typical broken dependency, which blocks all pending updates (including security updates!) unless the user installs packages selectively or excludes known broken packages. This must not happen. And when it cannot be avoided, everything that needs to be updated, ought to be prepared quickly. It need not be the packager's fault though. Download server mirrors, which are not up-to-date temporarily, can also be the culprit. Especially when the user has enabled access to multiple repositories, which contain packages that depend on eachother.
Bugs in the software
Here the key question is whether the bugs only affect Fedora or whether they are present in the software vendor's release and hence affect every distribution, which publishes the same release.
Amusingly, it is possible to find two Linux users, who use a different distribution with exactly the same version of an application which contains a bug, and only one of them says he can reproduce the symptoms of the bug. At first sight this gives the false impression that one distribution works better than the other. Only when looking under the hood (finding that neither of the packages contains important patches) and really trying to come up with a clear step-by-step test-case, the other user confirms that he is affected by the bug, too. It turns out the user just hasn't used the software in the same way. Sometimes the devil is in the detail. Different hardware, different configuration, differences in what is installed, differences in how the software is used. The list can get long.
In either case, when a problem is found, it's best to seek for support from the Fedora community via well-known mailing-lists or web-based forums. And, of course, bugs ought to be reported.
If upstream's software itself is free of bugs (sometimes upstream developers fail to reproduce a problem just like one of the users in above scenario until a test-case is made bullet-proof), possibly the seen misbehaviour is caused by
Usability related bugs in the packaging
These are even more interesting than plain broken package dependencies. Packagers can break the packaged software in various ways, e.g. misconfigure it, miscompile it, mispackage it, damage it with bad patches or incompatible build dependencies. If you have reason to believe something is broken, do report it to the package maintainer in bugzilla. Never assume a problem is obvious enough and will be found by the packager, testers or users other than you.
Please, let's distinguish between bugs in the software and packaging related bugs (including broken dependencies). Dividing the problem space makes it possible to focus on individual problems. For example, when discussing broken package dependencies, it is not helpful to hear that somebody is hit by bug somewhere in "Evolution".
And where is the real problem then? You don't seem to mention the problem any more than our foot-in-the-mouth friend, Eric S Raymond.
I've been using Fedora since the very first release and I've only had one problem to do with their package management - the X11 regression that killed the X server while upgrading Fedora Core 5.
That's it - exactly one problem caused by a genuine regression missed in testing.
Ubuntu meanwhile has had many more problems with bad packages - just look around at the history and mailing lists.
In my experience, Fedora has always been released with way above average quality of testing. Regressions are extremely rare. And problems are ALWAYS attributable to user-shenanigans - as was the case with ESR.
I have a feeling that your problems are to do with unrecommended ways of upgrading the system and - possibly - repository mixing with dubious quality repositories.
If that is indeed the case, you have little right to blame Fedora. After all, if you bought a Ford and went racing with it, you wouldn't expect Ford to uphold it's warranty would you?
And where is the real problem then? You don't seem to mention the problem any more than our foot-in-the-mouth friend, Eric S Raymond.
I've been using Fedora since the very first release and I've only had one problem to do with their package management - the X11 regression that killed the X server while upgrading Fedora Core 5.
That's it - exactly one problem caused by a genuine regression missed in testing.
Ubuntu meanwhile has had many more problems with bad packages - just look around at the history and mailing lists.
In my experience, Fedora has always been released with way above average quality of testing. Regressions are extremely rare. And problems are ALWAYS attributable to user-shenanigans - as was the case with ESR.
I have a feeling that your problems are to do with unrecommended ways of upgrading the system and - possibly - repository mixing with dubious quality repositories.
If that is indeed the case, you have little right to blame Fedora. After all, if you bought a Ford and went racing with it, you wouldn't expect Ford to uphold it's warranty would you?
I cut my Linux teeth on Fedora Core 1 and have been with the project ever since. Although I do run other distros on other cpus, my everyday CPU is FC 6.
I always upgrade my system and do not do a full reinstall. Do you know how annoying it is to get everything working again? Remembering all the programs you've installed. Getting all the settings right again. Forget that! So far I have not had an upgrade break my system.
Frankly, what I'd like to see is the ability to upgrade from within the system like Debain-based OSes. It's so annoying to have to download and burn a new DVD just to upgrade my system! I hope that F7 or F8 finally solves this problem.
Also I only have one other complained with Fedora and it was touched upon in another person's comments - what's with all the incompatible repos? I still don't understand why Fedora can't do like Debian. They could have one repo which is pure free software and then another one (multiverse, I think) which is all nonfree. Debian, which is so free that they rebranded Firefox as IceWeasel can do it, so why can't Fedora?
It's so annoying that FreshRPMS, Livna, and the others can't work together.
Since 1998, I have used RH6/7/8/9, FC1/2/3/4/5/6, Suse6/7/9, Mandrake/Mandriva 6/9/2006, Gentoo 2006, Ubuntu/Kubuntu/Xubuntu 5.10,6.06,6.10.
Bugs: Suse 9 had so many issues with Ethernet cards that I could not use networking. I gave up on Suse then. Xubuntu 6.06 could not print at all until I upgraded to Kubuntu 6.10 (and then still had to do some extra fiddling weirdness). Ubuntu/Kubuntu 5.10 would do an update that would remove the DHCP client from /etc/init.d. I had to manually add it back. FC4+ and all Ubuntu-family will only install GRUB, which means certain older WD drives are unbootable (which was why I went back to Mandriva for that system, as it gave me LILO's reliability back).
Oh, and I have never had any of them work with my wireless, even after days of installing this tarball and that one. I finally strung a cable to the other end of the house, so that my office has network capability.
My point? Every distribution has problems that drive some users away from it. In Fedora's case, they really do need to go to two repos: free and non-free. There does need to be far more testing before a release, since users see Fedora as free, desktop-oriented Red Hat. There really does need to be roll-back capability, and even with LVM, the /home directories need to be on a separate (accessible and preservable) partition, where users' settings and data can be preserved across upgrades or installations.
Although ESR's final problems are mostly his own doing, anyone who has used FC* over a period of years can tell about things like FC2's multiple-user issue (second regular user and afterward could never log in), or FC5's "Beagle indexing consumes 100% of CPU" issue. Or the yum and rpm take too long to find dependencies issue, which also tends to take up 100% of the CPU cycles. The distro has serious issues, to the point where I would abandon it if there were any others that didn't also stink.
Having said that, I am eagerly awaiting F7. I want to see if some of these problem areas have been fixed. The majority of my 12 machines will go to whatever distro finally satisfies and is fairly quick to install. The Gentoo machine currently satisfies, but it took far too long to set up.
yum is a problem. Try unreliable network connection and compare yum with apt. You will see differences.
Check ClarkConnect distribution too, they use RPM packages and manage them with APT. It is reliable solution.
I had problems trying to upgrade from FC 5 to FC 6 from CDs. The upgrade hung, for no apparent reason, while resolving dependencies. I did manage to upgrade from FC 5 to FC 6, but only by selecting a minimal set of packages, resulting in a useless (no X, no network) system. When I tried to upgrade the new FC 6 system from the FC 6 CDs, anaconda would not allow adding packages. Trying to upgrade by installing rpms manually from the CD put me in dependency hell.
I ended up nuking my system and installing from scratch, which had its own problems, given that I now needed to reconfigure many packages.
While I like FC, install/upgrade is a pain.
I may be dumb, but ESR failed to do one thing that those zaney Cathedral programmers do - test an update on a test machine before updating a production machine. Should it have worked - hell yes! But, his rant about an update killing his machine was silly, IMHO, since he took ZERO STEPS to protect himself.
Many in the Open Source software arena missed the opportunity of working in a real data center (raised floors, production schedules, documentation requirements, etc.), and don't understand that these aren't quaint habits, it is what you do to protect yourself.
I tend to keep one machine "sacred" in my office, one machine I don't futz with when the latest piece of soft or hardware comes along, I have plenty other boxes for that.
ESRs real problem as I read it was that his update failed, and that caused him to "dog pile" on the distribution for lots and lots of little things. IMHO, ESR should instead have written the classic "IMADORK" post and described how he was going to build up a test machine to support his production environment (laptop?)...
This article promted me to write about my own experience with "Fedora dependency troubles" upgrading from FC5 to FC6.
http://www.studt.dk/linux/Fedora-upgrade-5-to-6-b.txt
My response to Michael Schwendt:
Thank you for posting your comments. The fact that someone from the Fedora Project was willing to respond and takes these issues seriously says something very positive indeed about Fedora. I do appreciate you taking the time.
I removed Fedora Core 6 from my system over a month ago so I can't give specifics any longer. There were instances, both in FC5 and FC6 where the problem occurred strictly with Fedora Core packages, not Extras and not non-Fedora packages. When I load FC 7 onto my system I will certainly take you up on your offer of examining specific examples of the repository management problems I detailed. If it was a third party packages that were broken I would have no valid complaint.
I agree with merger of Core and Extras would be an excellent step.
I disagree that Firefox updates are so all-fired important that they must be issued immediately with no regard for what might break. It entirely depends on the nature of the upgrade and how serious the security issues (if any) are. Ditto kernel patches. In some cases the risk of exposure is very small and waiting a few hours or even a day to get everything working well together may be appropriate. I am VERY security conscious and I appreciate your desire to get patches out quickly. Sometimes it's really necessary but sometimes a small delay would hurt very little if at all. Most people would choose to keep their system keep working rather than applying a patch that breaks something critical to them.
I agree with you that the people posting comments are mixing up all sorts of issues. The issue I referred to, based on my own personal experience, is strictly one of broken dependencies due to poor repository management. It actually breaks into two issues that I've seen: 1) A package can't be installed due to a missing dependency and yum or pup crashes. 2) An upgrade installs perfectly normally but breaks a package which depended on the older version.
In the case of the first example a savvy user can configure yum to skip the offending package(s). A less than savvy user using pup is lost. At least in up2date you could exclude packages from within the GUI. That feature needs to be added to pup as well. Also, some other package management systems (apt, slapt) will inform a user of a broken dependency but then ask if you want to install the rest of the upgrades anyway. pup and yum also lack that functionality. Adding that would improve the usability of the Fedora package management problems a great deal.
The second issue, upgrading package A breaking package B, is far more difficult if you have just done a number of upgrades at one time. You need to then figure out what caused the breakage and roll back the upgrade provided you've configured yum to allow rollbacks. Again, this requires some command line savvy and is not user friendly. Having to figure out which package caused the breakage can be a daunting task.
Again, I appreciate your willingness to engage with me and to address issues people have posted.
More reply comments:
stolennomenclature: If you install a test distro you should expect to be doing alpha or beta testing. The whole idea is for you to find what is broken and report it, not for you to run code that isn't ready for prime time in production. Claiming that Fedora is unreliable because you have problems with test code is pretty silly. If you want it to just work wait for the official release.
I, for one, have never had a problem with Fedora or Red Hat Linux before it trashing a partition. I go all the way back to Red Hat Linux 3.0.3 circa 1995. Again, if you are running test code you have to expect problems.
W-L+:
Ubuntu installs lilo just fine. It's not grub only. You need to use a lower debconf priority to give you an expert installation where you can make more choices.
Yes, all distros have issues. Any large and complex set of software will. Windows does. MacOS does. Linux distros do. It's the nature of the beast. Having said that the problems I've described can't be dismissed or defended with the claim that other distros have problems. Again, this isn't bad code. It's bad management and it is inexcusable.
Hans Christian Studt:
The yum-utils skip-broken plug-in can skip packages with broken dependencies. Provided that you have it installed, you would add option --skip-broken when running yum.
Caitlyn,
When you begin to take your look at Fedora 7's final release, I would be happy to speak with you in person if you like as you put together your review.
My email address is easily found on my personal page at http://fedoraproject.org
>and excellent package management system used by more Linux distributions than any other.
To be true rpm is a pain in the backside. apt (Debian), pkgsrc (NetBSD, different Linux distros, Solaris), pacman (ArchLinux), ports in FreeBSD and so on are mature package management systems. You cannot compare yum to apt, don't even try it. Yum is a mockery of apt, a slow system on top of a hellish rpm - try to repair it, compare installation times. And I'm with Raymond ... he is some difficult character, but he is most of the time just honest.
I've just installed Ubuntu this morning on my Dell Inspiron E1505/6400. It boots in about 2/3 the time Fedora boots (37 sec vs 61 sec), the Wi-Fi JustWorks (Intel chipset), and the bluetooth work right out of the box. Does that make Ubunut better? No. I did not have a graphical environment as Ubuntu did not detect my ATI X1400 graphics card, and vesa does not support it. I had to google using lynx for about three hours until I found the solution in the Ubuntu bugzilla. That is less user friendly than Fedora had ever been to me.
I'll probably switch back around FC8 or so. I've been switching between them since FC3 and Breezy.
My biggest complaint with RH/Fedora/Centos is the GUI package management software.
I wish to install a piece of software, using the GUI, I choose it, and try to install it and the dependancy hell starts..
Does the GUI let me fix it, no... I get an "OK" and "Cancel" options, which essentially do the same things.
Also that error window is never big enough to see the entire message..
This is beyond poor.
Compare that to SuSe's YAST for installing packages.
Pick a package and install, get similar dependancy problems, but at least I have the ability to choose what options that can be taken to fix the problem.
Yes, I could drop to the command line and start doing things with yum, point is here, a computer is a tool, a labour saving device, and anything that increases the complexity of setup, decreases it's potential labour saving effect.
I guess I would have to echo some of the comments regarding the haste employed almost as a mantra by Fedora. Cutting edge is achieved, surely, but at the expense of reliability.
The solution for me, which is working quite well, was to move to CentOS 5. I made a complete backup of my FC5 installation, and then did a somewhat risky "upgradeany" install of CentOS 5. Surprisingly, only a few problems developed with broken dependencies, and they were fixed with a healthy dose of patience. By enabling the FC5 and FC6 repos in my yum.repos.d, I now have an extremely versatile and very stable installation.
I agree, it isn't rpm or yum which is broken, it is the hasty construction of iffy-if-at-all applications/programs. However, by moving to CentOS 5, most, if not all, of the slam-bam-thank-you-mam bugginess has been corrected and/or filtered out by the time it reaches the CentOS repos.
I would suggest that Fedora just slow down quite a bit, and make sure things really work before they release. Fixing some bugs is a price most Fedora users are willing to pay. Fixing really sloppy workmanship is not.
owa