up2date broken forever?

[kennon]

I have no problem using yum, infact when I have a boatload of updates to apply I pretty much default to it for speeds sake. But for the daily patches here and there having the RHN icon flashing red and being able to just launch up2date with a click is nice.

In the past with the stock FC3 install, and now with every version of FC4 I have tested, up2date never works. It says it is retrieving headers, I get the progress box then the main window goes straight to the Packages Skipped screen which is empty and the whole operation just kind of sits there forever. No headers are retrieved or anything. In FC3 I experienced this in the very beginning, but after using yum to get all the initial updates up2date started working normally eventually. I have tried restarting up2date over and over and sometimes it even get a couple headers downloaded but then it eventually goes straight to the Packges Skipped window before all the headers are downloaded.

Has anyone else had this experience? It has happened to me across multiple hardware platforms from a Toshiba laptop at work, to my older home PC, to my new home AMD64 machine, on reiserfs and ext3 file systems. I was just wondering if this was a personal problem, or if there was a fix that I am unaware of out there. ;-)

[pparks1]

You could type in
chkconfig --level 35 yum on

With this, your system will automatically run yum for you daily and you will never have to click on that icon.

I only use up2date on my Red Hat Enterprise boxes. I have moved strictly to yum on my Fedora, Centos and Whitebox boxes.

[kennon]

I am totally down with that. Nightly yum updates are super sweet. But I was really wondering if anyone else had seen this behavior. If this is a wide spread problem (I rarely ever hear anything positive about up2date) isn't this something that should be addressed by the devs? I would like to see some posts where people sing the praises of up2date. I never have, I instead see Yum Extender...GYum....etc...It just seems like this particular package is one of the potentially most valuable on the system yet very very few of the fedora users actually use it. I am not a windows convert, I have been using linux in it's various flavors now for several years but I kind of like a GUI for some things. The CLI is really powerful and I know it and love it, but if there is going to be a GUI alternative for what some people refer to as "The mainstream" whatever that means shouldn't it work? Shouldn't people like using it? I love using NmapFE, Gnome-Ethereal, GMPlayer, and a bunch of other apps that have CLI roots. But for some reason up2date is just flawed in some fundamental way. Well this is turning into a rant and this really isn't a place for that. I apologize. I was really just wondering if anyone else had the same problem I described with up2date or if I just had really bad up2date karma.

[mlcraig58]

I have seen this problem on FC 4 Test 3 as well (2 days ago). I ran up2date from the command line with the --nox option just to see if I was getting any error messages. Sure enough it was failing on downloading a couple of .hdr files. Seems like the GUI should have popped up some error for this but wasn't, and mine was jumping back to the package selection screen and just hanging there with the progress window sitting in front. Tried running it again last night and it worked without a hitch, go figure. It is a very unstable app IMHO since way back when (I've used Redhat since version 7) and I too wish it would get fixed once and for all.

[Finalzone]

up2date bug is fixed on my FC4T3. Beside, nightly yum updated solved the openoffice.org 1.99.104 dependancy issue.

[MrMoke]

Several Things:

First- I read somewhere in the documentation that the Fedora version of Up2date actually uses yum to update the system files.

Second- Yes, I have noticed the problem and formed a hypothysis based on almost no physical evidence. On several occasions I was working on the PC when the up2date button went red, and proceeded to run it immediatelyas a test. The results were similar to yours (failure followed by success the next day). Combining this with the observation that download sites seem to be picked at random, I concluded that the mirror sites may not be as up-to-date as up2date. If that were the case, then either the program is being told to look for headers and RPMs that don't yet exist on the selected site and failing, or the sites are merely so overloaded that they can't respond to requests in a timely fashion.

Either way it dies:(