If multiple installed resolvables in one selectable is the major problem, I
think we can go ahead and redefine the selectables like that.
So far, it is a very rare case that multiple instances of the same package are
installed at the same time. As a matter of fact, the kernel packages seem to
be the only ones that are (currently) even capable of that; all other
packages would get a zillion file conflicts right away.
So, let's not make that pathological case the norm that prevents all further
improvements. Let's have a selectable multiple installed instances.
BUT... (you had that coming, didn't you? ;-) )
We should change the API gently. There should still be a call that returns the
first installed instance.
Currently,
zypp::ui::Selectable::installedObj()
returns the one and only installed instance. Let's change this to
zypp::ui::Selectable::firstInstalledObj()
Let's also add
zypp::ui::Selectable::installedObjCount()
that returns the number (a plain int, not weird typedef'ed-to-death type) of
installed instances of that selectable.
The UI will have to handle the case of installedObjCount() > 1 differently.
But since it will affect only a couple of packages, this will be tolerable
IMHO.
I could imagine several scenarios:
(1) You can't simply change the status of such a selectable as with a simple
package where you have one (or none) installed and a number of instances
available. Rather, you'd
(1a) either have to use the "Versions" tab or
(1b) (better? worse? dunno yet) a popup opens when you click on that
status icon where you can do more sophisticated things with all the available
and installed instances.
Of course, we'd need another special icon (and internally a
status "multi-installed") to tell the user.
(2) The UI does the special handling for such selectables in a similar way
like today: Create multiple list entries, one for each installed instance.
CU
--
Stefan Hundhammer