Mailinglist Archive: zypp-devel (57 mails)
|< Previous||Next >|
[zypp-devel] libzypp - sat integration
- From: Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx>
- Date: Tue, 15 Jan 2008 13:31:44 +0100
- Message-id: <200801151331.48961.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.
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.
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.
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
|< Previous||Next >|