"zypper in foo" is the normal use at the command line level, you don't "zypper in foo-1.2.3.i586". Why should the graphical UI, supposed to be more userfriendly and less technical, display an arbitrary technical detail ?

But user might request installing a package coming from specific repository, thus (s)he (indirectly) requests a specific version, as the version can be different e.g. in main repository and in Packman. A typical use cases might be these audio and video players. So user rather thinks "I want an audio player from Packman and not from the main repository, as it can't play mp3's" instead of "I want MyCoolPlayer-1.2.3 instead of MyCoolPlayer-1.2.2"

If the user marks the candidate (having a specific version from a specific repository), this is very misleading.

I think the specific repository of origin of the package is more important to the user than its actual version. Come on, how many times (when installing a package via GUI or TUI) you really look at the column with version numbers? B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

* Katarina Machalkova [Feb 08. 2008 10:53]:

...

"zypper in foo" is the normal use at the command line level, you don't "zypper in foo-1.2.3.i586". Why should the graphical UI, supposed to be more userfriendly and less technical, display an arbitrary technical detail ?

But user might request installing a package coming from specific repository, thus (s)he (indirectly) requests a specific version, as the version can be different e.g. in main repository and in Packman. A typical use cases might be these audio and video players. So user rather thinks "I want an audio player from Packman and not from the main repository, as it can't play mp3's" instead of "I want MyCoolPlayer-1.2.3 instead of MyCoolPlayer-1.2.2"

Yes, fully agreed. One needs to specify version and/or repository. But thats the exception (imho) and one mostly is interested in the package name. So the default view should include the name, multiple versions or multiple repositories belong to the detailed view.

...

If the user marks the candidate (having a specific version from a specific repository), this is very misleading.

I think the specific repository of origin of the package is more important to the user than its actual version. Come on, how many times (when installing a package via GUI or TUI) you really look at the column with version numbers?

:-) That's exactly the point. I usually look at the name (and only the name). Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

* Cristian Rodríguez [Feb 27. 2008 01:56]:

Katarina Machalkova escribió:

...

I think the specific repository of origin of the package is more important to the user than its actual version.

Right, thanks for raising this issue, but I think *both* repository origin and version should be shown.

You might need a very wide monitor to show all this data ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Wed 27 Feb 2008 23:31:40 NZDT +1300, Klaus Kaempf wrote:

...

Right, thanks for raising this issue, but I think *both* repository origin and version should be shown.

I think it's important to have an easy way to see the repository a package comes from, esp for third-party repos. I found myself several times in the past where I couldn't see what upgrade will be going on when I click go, eg openoffice upgrade to the official suse one, the semi-official latest stable one, or the broken^H^H^Hexperimental one. When adding KDE repos for testing things get more complicated. I find the repo source to be as important as the package version.

You might need a very wide monitor to show all this data ;-)

There should be a way to show this without making the list any wider. Perhaps under a header, the header showing the repo, than the package list for that repo, then the next header for the next repo? A bit like the grouping of package selection in yast, the one with the orange/black scheme. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Stefan Hundhammer wrote:

We did that time and again, and the conclusion was always that we NEED something to display to the user.

They are questioning the ultra simplified and broken definition of "candidate", not selectables per se. I also question it. I think a Selectable should be grouped by a flexible policy (name, vendor, edition range, etc) and the candidate accessor should be removed, if the user selects install, the install request to the pool should be based on the capabilities of the defined grouping (requiring the name, the vendor, etc) and doing a solving which could result in one of the selectable members to transact, and not by a superficial candidate definition. The status of the selectable should be simply nothing if no member of the group transacts, and to be installed, removed if one of the other members is marked to do so. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

* Jan Kupec [Feb 08. 2008 12:30]:

Of course, if the solving is quick (or if it is done anyway upon every such user's action like selecting something to install), then the UIs have the information about the exact version which will really be installed and can show it. In that case, we surely don't need the 'candidate' at all.

Although I generally agree with this approach (immediate solving), the next 'click' in the UI changes the transaction and might trigger _a lot_ of changes. I think an undisturbed choice of 'install this', 'remove that' is better for the user, thereby building a(n input) transaction for the solver. Only when clicking 'Ok' (or 'Done'), the solver tries to solve the transaction and presents the result. (The 'immediate solve' checkbox can still be there, off by default). Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Stefan Hundhammer wrote:

Yes, that's what I meant, too.

My fear is that (again) in the course of the discussion all those who don't need it will agree to remove it, or to overcomplicate it (which is just as bad).

Actually I do think they can be removed, but not with the current UI "concept" (which is pretty old too) If anyone wants to remove or no improve them, he would need to propose a new user interface concept, because you just can't show package foo 45 times just because it is in 45 repositories. However, the candidate stuff, needs to go away, it makes every zypp application behave different. (for example Qt pkg selector does a manual transaction and chooses > version which breaks the not-jump-vendors policy ). Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Jan Kupec wrote:

Duncan, you mix two things here. One is 'removal of candidate', the second is the apps doing different things. This is completely unrelated! We are now in process of removing the latter problem - with the application layer. The former (remove, or not remove the candidate) is another thing. Am i right?

j.

They are related, even if the candidate is defined in the zypp layer, it overrides solver policies. So things like "Upgrade all in this list" just break all consistent behavior. Deleting a candidate is also the same, candidates don't exists, if you remove a Selectable it should inject a remove request to the solver of the capability which describes best the selectable (same criteria used for grouping), the solver is smart enough to look for a uninstalled package. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Jano Kupec wrote:

Klaus Kaempf wrote:

...

Right. And thats the problem I want to address. Showing a 'candidate' at the UI, one which might not be installed, his highly misleading.

"zypper in foo" is the normal use at the command line level, you don't "zypper in foo-1.2.3.i586". Why should the graphical UI, supposed to be more userfriendly and less technical, display an arbitrary technical detail ?

Let me add another example from the CLI (zypper) world. We have 'zypper list-updates' command which uses it's own (!!big no no!!) algorithm to determine the selectable candidate for an update and presents this version to the user. Then again, the 'zypper update' command uses the very same algorithm to mark the resolvables for actual update. This is for sure not a good solution when we want YaST packager, YOU and zypper (and any future libzypp app - like a CIM provider) to be consistent.

How this would be done if we drop the 'candidate-before-solving' concept? I guess like this: zypper list-updates will not show versions, it will just list the names of resolvables for which there are updates available. If the user is too curious, we need to make a solver run and see what did the solver choose to present it to the user (or should we always make a solver run to see if there are any updates for the installed resolvables?). A convenient solver/libzypp API would be then handy here e.g. solver.getCandidate(Selectable) which would return null pointer or throw an exception if called before solving. For the sake of completeness, this is actually what zypper {lu|up} --best-effort tries to do, but it does it again on it's own instead of just calling the solver and there's no convenient API to get the selected resolvables in order to present them to the user if requested. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Hi, On Tue, 26 Feb 2008, Jano Kupec wrote:

too curious, we need to make a solver run and see what did the solver choose to present it to the user (or should we always make a solver run to see if there are any updates for the installed resolvables?).

Always doing a solver run would be the best. Currently the solver can be configured towards certain modes/policies. One of them simply tries to update all packages to the newest version (to the extent possible, i.e. it won't give you a non-installable solution). That should be mostly what you want when you just call "zypper lu". (note: this is not the same as a dist upgrade though) Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Thu, Feb 07, Michael Matz wrote:

IMHO the concept of "candidate" is non-sensical when seen from only the solver side of things, as it is exactly a solvable.

In my mental model only "selectable" and "solvable" make sense. A selectable is a set of solvables (which happen to have the same name, but let's think of them as being an arbitrary set). Now there are two request types to give to the solver:

1) "please install this selectable": i.e. install one of the set members, I don't care which (policies and solvability will determine which one). The current form for this request is "install a solvable with this name" (as SAT solver job).

2) "please install this particular solvable": i.e. a specific solvable of which only exactly one exists in the SAT pool. For the application perspective it is perhaps interesting to note (but irrelevant) that this solvable is also an element of some selectable. But the solver request (as SAT solver job) is indeed "install solvable id so-and-so".

Right.

A "candidate" doesn't enter the picture, or if it enters at all then it is precisely the "particular" solvable of case (2) above.

Yes, but...

After solving the candidate doesn't exist anymore. Only the set of to-be-installed-or-deleted pool items exists. All of them happen to be elements of selectables, and some of them might be equal to what formerly were candidates (indeed, if a selectable contained a candidate then either the to-be-installed-or-deleted pool item is equal to it, or a solving problem occured).

The UI doesn't hande the case where '!=1' solvables are selected verry well. UI want's to display 1 version, 1 label, 1 description.... So if there is no unique solvable (pre)selected by the solver, the UI chooses one. Candidate is the item whichs data are displayed. Sometimes it is as well the one that gets installed. Sometimes it is not. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Tue, Feb 26, Jano Kupec wrote:

...

which gives you the one "interesting" solvable. So again, candidates don't make sense after solving anymore.

Why not call the one to-be-installed the 'candidate after solving' (forget the rare case where there are more such resolvables for now) and provide a method for that? It would make sense e.g. to present to the user which version will be installed AFTER solving and BEFORE proceeding with the

So you want a method that returns NULL if the candidadte object is not set to transact. I.e. it is a guessed one? -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org