Bugzilla – Bug 189298
Requestor for unfound files in YaST2 download
Last modified: 2006-10-17 22:19:06 UTC
Not sure if this is a real bug or someone's misplaced logic in requestor choices, but it doesn't work as it should. When presented to the user, the Abort Retry Ignore requestor comes up when a file is not found to download, upon selecting "ignore", the program exits without further file downloads. Assuming that Abort means to exit with no further action and Retry means to again attempt to get the file, shouldn't Ignore mean don't bother with this file, but continue with all others? Ignore should not mean the same thing as Abort, although in this case Abort means to stop completely any and all update functions. Someone's logic has apparently misconstrued the meaning of Ignore in this case. I get the impression Ignore is doing exactly what the programmer intended. Stop any and all downloads, but continue to the SuSEconfig script. Logically, Ignore should mean, ok, don't bother with this file, but continue with all other files selected, then run SuSEconfig. Ignore should only deal with that one problem file download, then move on to the next file, not exit!
Did you already install the package manager update _using YaST Online Update_? If not, please do it first. If the problem still exists, please attach the y2logs - you can save them using save_y2logs
I don't understand why you would want a log file when it's a simple matter of what the requestor choices do upon selecting them. It appears to do exactly what the programer has set it to do, even though his/her misplaced logic makes the wrong choices. It's totally opposite to what it means to the user. Just change the reaction of the program when Ignore is selected to skip this file and continue to download & install all other files selected for update. If Ignore is confusing to the programmer, then change the selection to "Skip" in the requestor! If there are dependencies for that unfound file with other files selected to download, then alert the user to that fact as well. To answer your question, yes, all updates have been applied to this crappy mono programmed yast2 mess you're trying to shove down our throats! Sorry for the sarcasm, but somebody should have complained internally when Novell requested this mess. Red Carpet & Mono has never, nor will ever work as well as QT/YaST2 did in it's previous state, before 10.1. If you need a y2log, run the program yourself and save your log. It will perform the same on your machine as it does mine. If you still need my y2log, then when do you start the save_y2logs program? Before starting yast2, after or while it's running?
In which situation this problem occured? There are many possibilities when this popup appears, which are handled differently. Logs would definitly help to identify where exactly the problem occurred...
(In reply to comment #3) > In which situation this problem occured? There are many possibilities when this > popup appears, which are handled differently. Logs would definitly help to > identify where exactly the problem occurred... > The problem I'm speaking of occurs in Yast2 after you have selected several files to update. Click accept, which moves it to the download and install window. As it's downloading the files, it hits a file it can't find or isn't there. The requestor appears, asking the user to Retry getting the file, Abort the whole process of updates or Ignore. The Ignore selection should respond by ignoring this file onl, unless there are dependencies at which time it should ask to remove the dependency files also and move on with the rest of the updates. As it is programmed now, the Ignore selection does the same thing as the Abort. It stops all further downloads and leaves the download & install window. The only difference I can see with Abort & Ignore is Abort quits everything, where Ignore quits the downloads & updates to ask if you want to Install more files or quit. Does that help a bit? I've not used that part of Yast2 recently, since configuring KYum/YUM, so I have no logs to report.
*** This bug has been marked as a duplicate of bug 181658 ***