On Tuesday 03 July 2007 11:58, Michael Andres wrote:
Historical. You may remember the first libzypp was a bit late, so there was little time to migrate the UI from using the old y2pm to zypp.
No. Not at all historical. The concept of "selectables" was the foundation of
the package selection user interface.
As a user, you don't want to deal with a dozen list items with the same name
(which is becoming a more and more realistic scenario with the
ever-increasing number of active installation sources). You don't want to see
something like
[ ] emacs 21.3-263.1
[ ] emacs 21.3-263.1
[x] emacs 21.3-263.2
[ ] emacs 21.3-263.3
[ ] emacs 21.3-263.3
[ ] emacs 21.3-263.4
just because you happen to have 5 active installation sources that each
provide an emacs package, plus your installed system that also has an emacs
package installed.
The selectable is what groups those resolvables of the same kind so we can
display ONE list items for "emacs".
Yes, of course, we could move that to the UI, too. We could let the UI iterate
over all packages and group those together that have the same name. Thus we
could move the handling of selectables to the UI level.
That's basicaly what the current zypp::ui::selectable implementation does. And
that's also the reason why there is no back-pointer, i.e. no way to move to a
resolvable's selectable parent. That's why we had to change EVERY SINGLE UI
function's API so they now accept both a zypp::ui::SelectablePtr and a
zypp::ui::ResolvablePtr. And of course it can only be hoped that they never
get out of sync.
The old package manager OTOH had that data structure in its core. A
PMSelectable had a list of PMResolvables, and each PMResolvable had
a "parent" pointer that pointed to its PMSelectable. Thus, one pointer was
enough to handle everything.
CU
--
Stefan Hundhammer