Mailinglist Archive: zypp-devel (68 mails)

[Jan Kupec <jkupec@xxxxxxx>]

Duncan, what i was talking about is storing all the rest of the data
other than NVRAD and kind in these methods:

  consumePatch()
  consumePackageAtom()
  consumeMessage()
  consumeScript()
  consumePattern()
  consumeProduct()

Do you want to code it, or shell i? There is some work on the YUMParser
stuff yet, but after polishing the code i'm free to do other things.


FILELISTS AND CHANGELOGS of YUM

Also, what has to be solved (with low priority, though) whether we can
support interface like:

void CacheStore::consumeFilelist( const data::RecordId &catalog_id,
const data::Resolvable_Ptr & resolvable, const data::Filenames & filenames )

This would mean querying the DB for the resolvable of given kind and
NVRA in given catalog and appending the changelog/filelist to it. You
said that it is not possible since the kind and NVRA are not unique
within one catalog?

If this would be possible, the YUM parser will have very low need for
memory (suse tags will probably not benefit from it(?)).

If we don't agree on this way (or if it turns out to be slow), then i
would like to have API like:

void CacheStore::consumeFilelist( data::RecordId &resolvable_id, const
data::Filenames & filenames )

With such API i will be remembering a map of yum package IDs to
resolvable record IDs and use it to insert the filelist and changelog or
whatever with still low memory foot-print.

Otherwise i will need to read all the package/filelist/changelog data of
all packages into memory.

What do you think?

Jano

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