Bug 308603

Summary: Regression: YOU don't automatically use full rpms
Product: [openSUSE] openSUSE 10.2 Reporter: Jan Kardell <jan>
Component: YaST2Assignee: Ladislav Slezák <lslezak>
Status: RESOLVED FIXED QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None CC: jsuchome, lslezak
Version: Final   
Target Milestone: ---   
Hardware: Other   
OS: openSUSE 10.2   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: yast2 logs

Description Jan Kardell 2007-09-07 11:24:11 UTC
Yast online update used to automatically fall back to using full rpms if the patch rpms were not available. I have used YOU this way for many years. With the latest updates a warning dialog box is shown for each missing patch rpm. When I press the cancel or skip button YOU tries the full rpm instead. It's quite annoying to press cancel for each patch.

It seems to me that this warning is placed in the wrong place in the program. This results in unlogical and annoying behavior of YOU. I would expect cancel really meant "cancel the update", not "retry using full rpm".
Comment 1 Andreas Jaeger 2007-09-08 08:39:33 UTC
Please add the YaST logfiles as described in http://en.opensuse.org/Bugs/YaST.
Comment 2 Jan Kardell 2007-09-08 22:51:34 UTC
Created attachment 162874 [details]
yast2 logs

Logs from a x86_64 system. I have several i586 with identical behavior.
I removed a couple of the oldest y2log-x files, the whole blob was to large for bugzilla.
Comment 3 Duncan Mac-Vicar 2007-10-02 20:09:57 UTC
Michael, how is the behavior in commit?
Comment 4 Michael Andres 2007-10-30 12:41:29 UTC
@Jiri: Please check, I thought it is already fixed.


Providing a package: after sending the 'start()' trigger a sequence of
DeltaDownload/DeltaApply/PatchDownload actions may be performed, and lead
to the 'finish()' trigger on success.


Each Patch/Delta action starts sending it's 'start...()' trigger, followed
by 'progress...()'. If the attempt is successfull a 'finish...()'
trigger is sent, otherwise 'problem...()' to indicate, that we're going 
to try something different.

This is no error the user should have to confirm, it's just an indication
to reset the progress bar as we're starting to try something different.


Only if the final attempt to provide the full package fails, reported by a 'problem()' trigger, the user should receive the error popup.
Comment 5 Jiří Suchomel 2007-10-30 21:00:52 UTC
I don't know to what you refer as "probably already fixed". I also don't understand which callback causes the reported action (so YaST Online Update might react inapproprietally...)

Comment 6 Michael Andres 2007-11-02 12:26:13 UTC
AFAIR we already faced this, so it might be there some fix that didn't make it back into 10.2 branch. But I'm not shure. May even be Ladislav is able to handle this completely inside pkg-bindings/PackageCallbacks.ycp.


Inside the DownloadResolvableReport providing some patch.rpm fails. This triggers MediaChangeReport passing MediaChangeReport::NOT_FOUND. But this should not cause any popup to appear. 

Inside DownloadResolvableReport only MediaChangeReport::WRONG indicating the wrong media is inserted should cause a popup - asking to insert the correct media. Or an error reported in the DoneProvide callback, as this indicates that even downloading the complete package failed.


Any other problem reported here is just informal.



Comment 8 Stanislav Visnovsky 2008-04-25 14:19:41 UTC
I believe this is fixed now. Please, reopen if you can reproduce with 11.0.