On Wed, Jun 27, Katarina Machalkova wrote:

...

I don't have any feature request for libzypp; we can work out things pretty easily (say, dependencies listing), and I think it already has enough bloat. :P

Well, the idea steadily evolved into something like 'writing a wrapper over libzypp' (called 'zypp4ui' for the time being) so that an application that

Not wrap - fix, improve and cleanup zypp.

needs to call libzypp function doesn't have to use libzypp low-level functions.

What is a 'libzypp low-level function'?

Example: in your application, instead of doing:

list <ZyppSelectable> patchList; for ( ZyppPoolIterator it = zyppPatchesBegin(); it != zyppPatchesEnd(); ++it ) { ZyppSel selectable = *it; ZyppPatch zyppPatch = tryCastToZyppPatch( selectable->theObj() );

if ( zyppPatch ) { patchList.push_back (*it) } } do_something_with_all_patches( patchList ); //example_end

one just does:

list <ZyppSelectable> patchList = zypp4ui::Patch::listAll(); do_something_with_all_patches(patchList);

This low-level iteration through zypp pool would be wrapped into zypp4ui::Patch::listAll(), so that your application just calls this function, without adding the iteration code itself into the code of your library.

The larger the ammount of objects you process, the worse it is to build a temporary conatiner just to process these items. Avoiding them and becoming more flexible is one idea behind the concept of using iterators, algorithms and functors. We have basic support for this. It for shure needs polishing before Huha happily uses it. ;) The Selectable IMO has a big drawback: It's the UIs request to have one Selectable for each installed item. While the Pool contains all individual items (packages, patterns,...), the Selectable groups them by name and kind. A Selectable(package,kernel) contians a link to one installed and all available kernel packages. This is fine as long as there are 0 or 1 kernel packages installed. Each kernel package known by the Pool is 'conected' to the same Selectable. Pool Selectables i:kernel-1.0 ---+ | a:kernel-1.2 ---+---- S(package,kernel) a:kernel-2.0 ---+ Unfortunately we support installing multiple versions in parallel. So if there are 2 kernel packages installed, we have 2 Selectables for (package,kernel). Each one connected to all available, but a different installed version. Pool Selectables i:kernel-1.0 ---+---- S1(package,kernel) ----+ | i:kernel-1.2 ---+---- S2(package,kernel) --+ | | | a:kernel-1.2 ---+--------------------------+-+ a:kernel-2.0 ---+ This missing one-to-one relation is basically the reason why Selectables were not integated into the Pool. A Selectable is not that helpfull because it does not neccessarily link to ALL (package,kernel) items in the Pool. It lacks information that might be required to make decisions. And vice versa a Pool item as result of some query does not necessary lead to only one Selectable. Pool NameKindProxy i:kernel-1.0 ---+ i:kernel-1.2 ---+ +---- NKP(package,kernel) a:kernel-1.2 ---+ a:kernel-2.0 ---+ NameKindProxy does, what Selectables IMO should do, it links to all known Pool items of certain name and kind. And each Pool items is connected to one NameKindProxy. An object like this can easily be kept and maintained in the Pool. Pool items can contain a backlink to the corresponding NameKindProxy It would be a good place to provide convenient status manipulating methods. It could use the same policies as the solver to e.g propose the 'best' package for install or upgrade. Everything you improve here, will be available to all zypp based applications (zypper, pkg-bindings,..), and not just for the YaST UI. The UI Selectable would be a good candidate, IF it could avoid the duplicate Selectables. -- 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