Mailinglist Archive: zypp-devel (52 mails)

[Klaus Kaempf <kkaempf@xxxxxxx>]

* Duncan Mac-Vicar P. <dmacvicar@xxxxxxx> [Sep 05. 2011 11:19]:
> On 09/02/2011 10:53 AM, Klaus Kaempf wrote:
> > * Michael Andres<ma@xxxxxxx>  [Sep 02. 2011 10:49]:
> > > We can also work on the zypp solvers API side. AFAIK the solver is basically
> > > able to resolve requests like 'install one out of a set of packages'. 
> > > There's
> > > just no zypp side api for this.
> >
> > The complete solver api, including policies, is available in the
> > satsolver bindings. Exposing these in the libzypp bindings should be
> > fairly simple and also prevent from re-inventing the wheel.
>
>
> While it would be cool, it has the following problems:
>
> - satsolver is not different to libzypp. Is not a task oriented API
> but a model of the problem domain. Not to mention it does 30% of the
> problem

You have looked at the satsolver-bindings and the example code ? Can
you provide an example to make it even more task-oriented ?

> - As Michael mentioned, libzypp does not allow raw manipulation via
> the satsolver API on one side and then using libzypp on the other
> side
See my previous mail. I think this is wrong.

> - Almost every client tool where we want to reduce code duplication
> is not using any scripting language. We want to offer bindings for
> _future_ tools.

Shouldn't future tools be implemented in a scripting language ? The
porcellain/plumbing model, e.g. git is using, seems very desirable to
me.

> - While moving away from libzypp sounds like simplifying the
> problem. I think is just an instance of a known mistake:
> http://www.joelonsoftware.com/articles/fog0000000069.html

Is anyone proposing to move away from libzypp ?

> I think that having functional code in the bindings is re-inventing
> the wheel.

Can you give an example for this concern ?

> Any code not using scripting languages would need to
> rewrite that code.

Which code not using scriting language are you envisioning ?

> I experimented during the weeked with the small API
> (zpm_query_what_provides and zpm_query_search) using 2 different
> approaches:
>
> - Using libzypp, and hiding its classes into this light swig friendly API
> - Using satsolver only. Reusing code by mls in his example solv.c
> (parsing and download of repos, download of packages, etc).

This compares apples with oranges.

> The feeling I got doing those experiments:
>
> - A C task-oriented API would allow zypper, YaST and PackageKit to
> deduplicate code  and if the API is good, nice bindings.

Ah, so you're targeting a C api here. Then using SWIG is certainly the
wrong approach.

However, I currently cannot imagine many consumers of a C API.

> - ZYpp is a great way to implement this API. Using the plain
> satsolver was not bad at all, but is a very raw API

Thats why satsolver-bindings provide a (C language) 'applayer', making
the satsolver API much more approachable.

> - Implementing all the other requirements: memory management,
> selectables, powerful filters and search, key management, repository
> management, media abstraction, etc in plain C together with the
> satsolver (basically the experiment I did using mls solv.c code) is
> a step backwards.

Of course ! And noone is questioning that.

The question is how to provide bindings for the objects shared between
libzypp and libsatsolver, like 'Solvable', 'Solver', 'Problem',
'Solution', 'Transaction', 'Pool', 'Repo', etc.

My proposal / offer is to use the API already existing in
satsolver-bindings for the shared objects.

OTOH, given sufficient time and resources a completely new approach is
possible.


Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 
16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx