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@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org