http://bugzilla.suse.com/show_bug.cgi?id=1162143 http://bugzilla.suse.com/show_bug.cgi?id=1162143#c1 --- Comment #1 from Rodion Iafarov --- Created attachment 828586 --> http://bugzilla.suse.com/attachment.cgi?id=828586&action=edit YaST logs -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1162143 Stefan Hundhammer changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|yast2-maintainers@suse.de |shundhammer@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1162143 http://bugzilla.suse.com/show_bug.cgi?id=1162143#c3 --- Comment #3 from Stefan Hundhammer --- The selected version in the "versions" tab is the candidate version that you will get if and when the package will be installed or upgraded. When you click on a package version manually that is different to the one that is currently installed, this automatically also changes the package status to "upgrade" (which may also be a downgrade). I think it's similar with packages that are not installed yet: If you click on a specific version, this will also set the package status to "install". But that's all just convenience. The rationale is that if you explicitly select a specific version, you probably want that version to be installed, so the package selector also does the other action: Change the package status accordingly. For retracted package versions, things are different, though: We cannot automatically decide that it's best for the user to install a different version. In the typical use case this means a version downgrade which in turn may trigger other package downgrades because of package version dependencies. This may easily lead to dependency problem reports that may be hard to resolve. Having retracted package versions in the first place means that doomsday is near; something went terribly wrong. Having retracted package versions installed means you are in the middle of doomsday, and meteorites are impacting all around you. When the concept of retracting patches was brought up (and thus retracted package versions became a possibility as a consequence), it was decided not to automatically downgrade anything. Solutions how to handle the case that a user was quicker installing patches than our maintenance team could realize that they are broken and need to be retracted included anything from "the user needs to reinstall that system" (ouch!) to "tell the user to sit tight and wait until we release a fixed version". A user may decide to try to downgrade individual packages manually. This may or may not work as desired; it may lead to the aforementioned dependency problems. But the desired behavior was not to make the package selector do anything that would initiate such a downgrade half-automatically which is the behavior you observed here. The only consolation is that all this is a very unlikely scenario which we are doing our best to avoid. Once users are in that scenario, we need advice on a case-by-case basis and publish that advice (as a security advisory?) in a high-visibility public place. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1162143 http://bugzilla.suse.com/show_bug.cgi?id=1162143#c5 --- Comment #5 from Stefan Hundhammer --- To clarify some more: The behavior to have a candidate version that is not the same as your installed version is perfectly normal. Normally, the latest version is also the candidate version; a retracted version, however, will never be a candidate version (libzypp / libsolve make sure of that). Just because there is a different version that is considered the candidate version does not mean that the package selector automatically upgrades (or downgrades) to that version; you still need to do that manually if you wish to upgrade. To see this, just do "zypper refresh", start the Qt package selector, select the "Installation Summary" view, make sure the "Keep" status is checked on the left side and sort for column "Installed (Available)". All blue versions have a newer version available. Click on any of them and switch to the "Versions" details view. You will see that every single of those blue packages has a different version preselected than is installed; those are the candidates that you will get when you choose to upgrade. But it will not set those blue packages to "Upgrade" if you don't tell it to do that. This behavior is perfectly normal and absolutely desired. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1162143 http://bugzilla.suse.com/show_bug.cgi?id=1162143#c7 --- Comment #7 from Rodion Iafarov --- (In reply to Stefan Hundhammer from comment #5)

To clarify some more:

The behavior to have a candidate version that is not the same as your installed version is perfectly normal. Normally, the latest version is also the candidate version; a retracted version, however, will never be a candidate version (libzypp / libsolve make sure of that).

Just because there is a different version that is considered the candidate version does not mean that the package selector automatically upgrades (or downgrades) to that version; you still need to do that manually if you wish to upgrade.

To see this, just do "zypper refresh", start the Qt package selector, select the "Installation Summary" view, make sure the "Keep" status is checked on the left side and sort for column "Installed (Available)". All blue versions have a newer version available. Click on any of them and switch to the "Versions" details view. You will see that every single of those blue packages has a different version preselected than is installed; those are the candidates that you will get when you choose to upgrade. But it will not set those blue packages to "Upgrade" if you don't tell it to do that.

This behavior is perfectly normal and absolutely desired.

Main point is that current behavior is not obvious. In ncurses it's even more confusing as we have unnamed column with x in it and then status, e.g. `i` for installed. I would expect that they select same version of the package when user has selected it, if not, then it should do what it shows in the UI. It does neither of two, leaving as it is. In qt at least we have installed version being shown as label, but that's also confusing as it appears like there is another version in the main repo, even though it's same version. So in case you disagree, that it might be confusing for the customers, we can leave it as invalid and I guess we can also stop wasting your time and not raise such issues in future as 99% of UX issues are ignored with similar arguments. You don't need to explain how we can make it work, and there are zypper coomands. I didn't use this module much, but I can tell you that when I expected some change and window got simply closed, so I had to start all over, wasn't best experience. If it's desired that way - we can improve it with minor changes. So, as stated above, if there is no interest in such feedback (and I don't know better place than bugzilla for such discussions), we won't waste your time on explaining how it's desired to work and raise only functional issues. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1162143 http://bugzilla.suse.com/show_bug.cgi?id=1162143#c9 --- Comment #9 from Stefan Hundhammer --- For the record: We just talked this over personally and exchanged our different views. -- You are receiving this mail because: You are on the CC list for the bug.