Mailinglist Archive: zypp-devel (102 mails)

[Michael Matz <matz@xxxxxxx>]

Hi,

On Wed, 11 Mar 2009, Michael Schroeder wrote:

> > I sometimes thought about splitting the common code of tools/*.c 
> > (there's much, in particular the several XML parsing constructs) into 
> > a new libsattools library, which would also contain the repo_write 
> > stuff.  Eventually I get to that when I do the static->shared lib 
> > transition.
> >
> > I would hope it's acceptable for you to have to link against an 
> > additional lib.
>
> I don't know why the repo_* functions can't live in libsatsolver.

(They obviously _can_, which isn't the same as _should_ :) )

I don't see a reason for e.g. repo_deltainfoxml.c, or generally all the 
different converters to be in libsatsolver.  IMO it should consist of 
exactly the stuff to load SOLV files and do the solving and reporting, and 
nothing more.  That repo_helix is in there is just an artifact of the 
checker program needing it.  It could have linked against that other lib 
if it existed.

My reasoning for this is my usual strive for "lean and mean".  E.g. I 
could imagine for libsatsolver to be in a very small image that's good for 
installing only, and only when you get SOLV files already.  I would be 
annoyed if that library would be bloated by useless converter or SOLV 
writing code.

I basically don't see what should be bad about having two libraries.

> They were always meant to be in there. I think they were excluded 
> because they add dependencies to external libraries, but we now have 
> repo_helix (yuck!) in libsatsolver so that reason is moot.

We can move it out again, once we have a place to move it to.


Ciao,
Michael.
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx