|
Bugzilla – Full Text Bug Listing |
| Summary: | Yast2-gtk selector: arch agnostic | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Bjørn Lie <zaitor> |
| Component: | YaST2 | Assignee: | Michael Meeks <mmeeks> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Major | ||
| Priority: | P2 - High | CC: | forgotten_h13THG8RK1 |
| Version: | Alpha 2 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 11.0 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
yast2.log
Screenshot |
||
Created attachment 198137 [details]
Screenshot
Thanks for the report. We are now showing the architecture together with the version number, as well as the release suffix. Also inlined the conflict details, instead of using tooltips, because Zypp Solver changed their semantics -- so it will show the details after that "Following actions will be done:" item. |
Created attachment 198136 [details] yast2.log Look at screenshot, yast suggest a i586 rpm as a upgrade for me. And there is no way for the user to see that he is installing a i586 rpm - In this case the solver stops it, but this is broken design I found the reason (I think/guess), factory is not in sync i | Main Repository (OSS) | pakke | libzypp | 4.2.10-4 | i586 i | Main Repository (OSS) | pakke | libzypp | 4.2.10-3 | x86_64 i | Main Repository (OSS) | kildepakke | libzypp | 4.2.10-3 | noarch i | Main Repository (OSS) | kildepakke | libzypp | 4.2.10-4 | noarch i | @System | pakke | libzypp | 4.2.10-3 | x86_64 See libzypp is at a higher build for i586, but there is no way to see that in yast2-gtk, it only shows 4.2.10 + yast shouldn't suggest i586 rpms as upgrades anyway. One can claim that this won't be a problem with a "release" since the version numbers should stay in sync there. But consider the fact that users will be adding 3 party repos, where this can happen all the time. This puts the user at peril, since they will go ahead and upgrade themselves into a broken state.