Mailinglist Archive: yast-devel (156 mails)

< Previous Next >
Re: [yast-devel] Adding missing API to libzypp (or between libzypp and apps)
  • From: Michael Andres <ma@xxxxxxx>
  • Date: Fri, 29 Jun 2007 11:08:01 +0200
  • Message-id: <20070629090801.GA28683@xxxxxxx>
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@xxxxxxxxxx
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: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups