Mailinglist Archive: zypp-devel (57 mails)

[Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx>]

I have been looking into libzypp sat solver integration, trying to help with 
pieces that I am more familiar with. Looking at the code, porting and 
integrating helps by having a better overview of missing pieces.

Right now I have found the following issues/questons.

- parsers: 
There is no parser and attribute storing for plain rpm dirs. And the rpm code 
is not reusable to do it. (target::rpm in zypp actually is shared between the 
target and repo::plaindir). Most parsers attribute storing is incomplete too. 

What I am trying to do is creating a SolvStore that works with the current 
parsers so I can move blocks without changing much code, and minimize risks 
when using new pieces (especially if they get complete). It also helps to get 
familiar with the attribute store.

- repo-status

The old cache had an attribute per repository which allowed to save the 
checksum and timestamp of the repo raw metadata index so you could know to 
which version of the raw metadata the cache was generated from. I will 
simulate this right now by writing a file $(alias).cookie in the same place 
as the .solv file I guess.

- target

the rpm code is not only used to read installed packages. but as I mentioned 
above, it is used in the plaindir code and also it implements some helpers 
that deal with patch-rpm querying for installed versions. Ths means basically 
that target rpm code has to stay or be ported to use information from sat 
pool. Even if it stays, the keeping rpm and it solv file means changes to the 
target class and perhaps the repo manager.

we store right now installed patterns, patches, and other non-rpm types in a 
xml store. This would make sense to be ported to a single solv file plus an 
attribute store, and merge it into the rpm solv and attribute at runtime or 
on disk. However, this also needs work.

- delta rpms and patch rpms

libzypp sqlite cache keeps delta and patch rpm information in the database. 
There are 3 special tables for this. This information has to be stored 
somewhere.  Yes, we could keep a "sqlite part" only for this, but it feels 
unconfortable. If I can reimplement the CacheStore as a SolvStore, I could 
stll try to implement the delta and patchrpm metadata as sqlite. Will see.

- satsolver-io functions

- we need to expose them, right now there is no public api to write a solv 
file, to read a repo, etc. This is work we need to do _now_.

- sat classes and pool string space

This is not an issue, but a desgn problem which makes thing unconfortable but 
there is no "best" solution either.
Right now, sat wrapper classes, are only composed of the  Id plus some helper 
methods. For example, architecture as compatibleWith() method, etc.
Those classes Id are based on a global "pool". However while parsing (i am 
talking from the POV of using the current code), you don't want to mess with 
the global pool. But you want to use those nice classes instead of dealing 
with dumb objects like as a string as an architecture (yes, to check 
compatibility right now I have to promote the string to an Arch just to use 
the helpful methods). Right now those classes can be created being associated 
to another pool, because then every object would contain data and it would be 
no "light" anymore. This sucks.

That is for now, I will update as I discover more things.
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx