2009/7/4 Cristian Morales Vega
Some time ago I wrote about the problems in the software management stack. At that time zypper was a good tool, but the GUI apps did too much by themself without asking libzypp. Now I have added the zypp:Head and YaST:Head repos to my openSUSE 11.1, and that's what I see (looking at the QT version of sw_single, no idea about GTK):
The good: 1- The YaST search now is a lot faster than in default 11.1. 2- As explained in http://jniq.blogspot.com/ the zypper interface now it's a lot better.
The bad: 1- It's my understanding that sw_single still hasn't an equivalent to "zypper update". Neither Package->All Packages->Update if newer version available/Update unconditionally do the same. No sure if for single package installs the dependency resolution now is equivalent to zypper.
2- The vendor thing... OK, I don't see where the problem is, but it seems users have a problem when YaST ask them if it's ok to do a vendor change. They just see a "dependency conflict" and get scared. I would say that dialog could indeed get an update: 2.1- The classic situation gives three options: "vendor change", "do not install" or "ignore deps". Neither of them selected by default. Since users report that they click "OK" and they don't see any change (normal, they selected to do nothing) I would suggest two alternatives a) Enable the first option by default. Is ZYpp really returning them in an order that makes sense? b) Disable the OK button until the user selects an option. 2.2- The vendor change option could be reported with a better layout I get:
Conflic Resolution: <radiobutton> Following actions will be done: install <package> (with vendor change) <previous vendor> --> <new vendor>
more... <radiobutton> do not install <package> <radiobutton> ignore some dependencies of <package> So 2.2.1- The first radiobutton is in "Following actions will be done" and should be in "install <package> (with vendor change)". That could be a problem because of my mix of 11.1 and Factory packages. But if isn't it is a bug. 2.2.2- "<previous vendor> --> <new vendor>" is easier to read if is in a single line, I don't see space problems. 2.2.3- "
more..." isn't clear. The "number" is lines of text, packages or what? Only once you click you see it means lines of text, that I would say isn't the best option... number of (more) packages that need a vendor change would make more sense. 2.2.4- "ignore some dependencies" is too dangerous. I would hide it and only show it if the user has activated an "advanced" mode in YaST sw_single. 2.2.5- Since now we have only two option (vendor change or do not install) I would argue that all the dialog should be redone. I would argue that there should be two dialogs, one specific for vendor changes and another for "real" dependency resolution problems that require a decision from the user. The vendor change specific dialog would say something as: "The selected action requires to change some packages for versions provided by different vendors. If you subtitute an official package from openSUSE by one provided by a third party you will lose the support from openSUSE. If you continue these packages will be subtituted by others from different vendors: <packageA>: --> <packageB>: --> " An "OK" would be equivalent to the current first option. A "Cancel" would be equivalent to the current second option. If the user clicks on "Cancel" he will return to the main sw_single window and the package that triggered the vendor change will be unselected (now the package continues marked for installation, so the conflict dialog will show again at some point). I mean, if I mark libxine1-codecs for install I get the dialog asking for a vendor change of libxine1... if I click on "cancel" libxine1 isn't marked for installation but libxine1-codecs is keep marked.
2.3- An alternative option is to add another option to the main sw_single module: "Force resolution". It would be the same option available in zypper. If "Force resolution" is enabled YaST will not ask the user when there are multiple possibilities, it will select the options it thinks it's better automatically. zypper forces resolution by default for "install" and asks the user for "update".
3- The updater applet from default 11.1 can only update patches. It seems a problem in PackageKit, that only knows about a single update, not about patches/packages. IIRC it's already reported in bugzilla. No idea if it's already fixed in Factory and I don't see a package backported to 11.1.
So... for what should I open a bug? The lack of a "zypper update" equivalent in sw_single is known since a lot ago. Any plans to fix it for 11.2? Since you have been working on the zypper interface, can I suppose you are already also working in the YaST interface to solve problems as the vendor change dialog I just explained?
I would summarize the current situation as: "with the new zypper interface I don't need the GUI anymore, but if I would want to use it I couldn't.". Because the lack of "zypper update" for GUI apps is a really big problem if you want to use them.
Another one, see http://forums.opensuse.org/applications/multimedia/419403-libxine1-requireme... Once again I think the message is already clear. But perhaps could be clearer... Once again we have three solutions: Solution 1: do not ask to install a solvable providing libxine1 = 1.1.15-20.8 Solution 2: do not ask to install a solvable providing libxine1-codecs Solution 3: Ignore some dependencies of libxine1-codecs And once again we have a solution that probably should not be shown ("Ignore some dependencies") and a solution that is equivalent to "Cancel" ("do not ask to install a solvable providing libxine1-codecs")... and yes, the only left solution (that probably should be selected by default) could be better worded. Could ZYpp be changed so in cases were an upgrade is needed a special message is shown? In this case instead of "do not ask to install a solvable providing libxine1 = 1.1.15-20.8" it could say something like "install a newer version of libxine1: 1.1.16.3-0.pm.3 instead of 1.1.15-20.8". If solution 2 and 3 are removed something similar to point 2.2.5 could be done for these cases. A new, specific dialog for cases were a newer version than the already selected is needed. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org