Bug 332484

Summary: online updates: incorrect pattern/package status
Product: [openSUSE] openSUSE 10.3 Reporter: macias - <bluedzins>
Component: libzyppAssignee: Thomas Göttlicher <tgoettlicher>
Status: RESOLVED DUPLICATE QA Contact: Duncan Mac-Vicar <dmacvicar>
Severity: Normal    
Priority: P5 - None CC: jsuchome
Version: Final   
Target Milestone: ---   
Hardware: i586   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: OU
version 1
version 2

Description macias - 2007-10-10 09:38:13 UTC
In SM it is pretty straightforward, however in OU it is puzzling.

I ran OU, I saw ~10 patterns, 8 was with status keep, 2 with refresh. All packages in patterns were marked as keep.

What would happen in SM? Nothing. What happened in OU -- all packages marked as keep were refreshed.

To be exact -- I previously made another test, what "do not modify" means. So I selected all packages and marked them as "do not modify", except for one pattern (gtk2) where I marked them as refresh. Now, all of the suddent there were tremendous number of conflicts -- which (note: "do not modify" status) simply means my current system cannot exists, because if conflicts are with such status it means also that conflicts are in my currently installed system.

Please use status marks in OU in the same way they are used in SM, so the user could easily update for example one pattern.
Comment 1 Jiří Suchomel 2007-10-10 20:47:01 UTC
Huh? What's SM and what is OU?
Comment 2 Jiří Suchomel 2007-10-10 20:51:37 UTC
Ah, OU=Online Update, SM=Software Management :-)

The status marks should be the same, as the UI is done by the same part of the system. 

> I previously made another test, what "do not modify" means. So I
> selected all packages and marked them as "do not modify", except for one
> pattern (gtk2) where I marked them as refresh. Now, all of the suddent there
> were tremendous number of conflict

I am not sure if I understand correctly, but if you set all but one pattern as "taboo" and the remaining one for update, it seems logical to fail on dependencies because this pattern most probably requires software from other patterns.

So I still don't get it where's the problem. Could you attach screenshots and/or y2logs?
Comment 3 macias - 2007-10-11 12:55:26 UTC
Created attachment 177681 [details]
OU
Comment 4 macias - 2007-10-11 12:57:48 UTC
Jiri, maybe instead of explanation take a look at the OU screenshot (yes, OU is online update :-) ).

Now, please look ONLY at kernel pattern. You see those [>] marks. They are visually the same as in SM and the meaning (in tooltips, in context menu) should be the same, right? 

What will happen when I hit "accept"?
Comment 5 Jiří Suchomel 2007-10-11 13:23:07 UTC
I don't see any patterns. In the left part of the window, there are 2 patches selected for installation (both with [>] mark) - "kernel" and "km_drm". You have "kernel" patch selected and you can see that this patch contains kernel-default and kernel-source packages that need to be updated.

Anyway, this is an issue of the UI. Maybe Stefan can help us if I am describing it incorrectly or if there is some real problem.
Comment 6 Stefan Hundhammer 2007-10-11 13:34:23 UTC
I have no clue what this is all about. The bug description is confusing. Somebody please explain. 

And I'd really appreciate if we could keep the number of meaningless acronyms down. This only adds to the confusion.

I see the screenshot. So what's the problem with that?
Comment 7 macias - 2007-10-11 14:09:48 UTC
> You
> have "kernel" patch selected and you can see that this patch contains
> kernel-default and kernel-source packages that need to be updated.

That exactly my point! But the marks near those packages are [>] which means _keep_. It should be "refresh" because when I click "accept" those packages will be changed, right?

Current UI (visually) is confusing -- because when you look at status marks (and colors) you could say nothing will happen. So my concern is the visual marks are not "compatible" with SM (software manager). There should be clear indication the patch is installed and what packages are affected.
Comment 8 Stefan Hundhammer 2007-10-11 14:32:50 UTC
The icons in the package selector reflect the status of the corresponding zypp::Selectable. The package selector never stores any status information, it always retrieves up-to-date information from the libzypp back-end.

So it's not a UI problem. If it is a problem, it's somewhere else.
Comment 9 Duncan Mac-Vicar 2007-10-11 15:02:03 UTC
Maciej, could you point out what appears for both packages of the right in the screenshot in the versions tab (I want to see what is avalable and what is installed)
Comment 10 macias - 2007-10-11 15:27:36 UTC
Created attachment 177774 [details]
version 1
Comment 11 macias - 2007-10-11 15:28:28 UTC
Created attachment 177775 [details]
version 2
Comment 12 macias - 2007-10-11 15:30:24 UTC
Duncan, of course this is just an example. It happened before -- all [>] marks (with or without blue color) and after "accept" everything what I saw in OU was updated (i.e. patched).
Comment 13 Duncan Mac-Vicar 2007-10-12 14:18:45 UTC
Maciej, you are right.

Actually what seems to be missing is a solver run at the beginning. I figured it out when I went to the patterns view and selected a pattern for installation, went back to patches, and the kernel patch related packages now show the right icon.

I closed yast online_update, start it again, and this time I just press the button check dependencies, and the icon status are fixed.

Still I consider the problem really minor.

Can you confirm the behavior of "check dependencies"?
Comment 14 macias - 2007-10-12 16:09:03 UTC
I can confirm. But I don't think the problem is minor -- look, you don't know about this issue, you start OU, you do something with one package only (let's say it takes 4MB), you click accept happy you are about to download 4MB. And all of the sudden you are downloading 100MB who knows for what packages. At this point you could say it is really random -- OU updates your system in a way you didn't want!
Comment 15 Duncan Mac-Vicar 2008-01-29 09:34:09 UTC
Ok reassigning to Thomas bug collection.

I guess the solution is to do a solve when starting. (Comment #13)
Comment 16 Thomas Göttlicher 2008-01-31 16:52:02 UTC

*** This bug has been marked as a duplicate of bug 340898 ***