On 07/04/2009 06:40 PM, Cristian Morales Vega wrote:
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.
It's not. 'zypper in --name package' is almost equivalent (well, it actually has a bug, ignoring repo priorities), but otherwise zypper creates other type of request for the solver. The results are mostly the same, but i guess not always. Yes, we should try to clean this up, so that we get the same results with both zypper and YaST.
2- The vendor thing...
I'ts not just the vendor thing; it's the dependency problem dialog in general.
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?
I'd say yes. But this is a question for Michael (mls).
b) Disable the OK button until the user selects an option.
Makes sense. Thomas?
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
That would be OK, if there was only one action needed. But what if multiple are needed (as in your case)?
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.
This is already done in libzypp 6.13.0: - Remove confusing newlines in vendor change info (bnc #503859)
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.
It's a list of the other actions from "The following actions will be done". It does not need to be vendor change. It can be install, upgrade, removal, arch change, ... Maybe "plus # more actions" would be good.
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.
Not a bad idea. But libzypp would need to provide API allowing the app to recognize the "ignore some deps" option. The problem is that the text is shown as it comes from zypp. We would either need to enhance zypp API to give the apps all the deails (or at least more of the details) about the dependency problems in some structured objects, or the apps need to parse the texts and reformat it or act on it as it suits them. I'd say the latter is nonsense, and the former is quite some work (the number of possibilities is quite high when it comes to solving of dependencies).
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.
Both require a decision from the user, as long as s/he cares from which vendor the packages are installed. Those who do not care should put their trusted vendors to /etc/zypp/vendors.d. Maybe we should provide a UI for this (like "consider this vendor equal to openSUSE" or "trust this vendor" checkbox, with a detailed help describing what it means). But AFAIK, most people care whether some packages come from packman or suse, since packman can handle more multimedia formats, for example.
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.
I like the idea, but i'm afraid it won't be doable in cases like you described in the beginning of your post. But it can be done like this simple cases, where the vendor change is the only issue and action to be done. This, too, needs a change in libzypp API. I meantion this all the time becase all in all, all of this would require quite some work in libzypp, and i'm afraid we do not have resources for that. Help would be surely appreciated.
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.
Hard to avoid this, AFAICS.
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".
"Force resolution" is just about allowing the solver to start removing packages as it sees fit in order to avoid dependency problem dialog. It's not about vendor changes or multiple options to resolve a dep problem, AFAIK. It's convenient in zypper - if you don't like the result, you try again without "force resoltuion" and look at the result. But it could be counterproductive in a GUI.
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.
Not a bug, but a fate request would be nice.
Any plans to fix it for 11.2?
None that i know of. Thomas? Duncan?
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?
Your suggestions make sense, but it's all quite a bit of work, and i'm afraid we're out of resources at least for 11.2 :O(
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.
Agreed. The doUpdate() algorithm used by 'zypper up' is a good thing. -- cheers, jano Ján Kupec YaST team ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz ---------------------------------------------------------(EOF)--- -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org