Bugzilla – Bug 156452
factory service add needs ~ 750MB
Last modified: 2006-06-15 20:21:42 UTC
A rug service add call rug sa --type=yum http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse "factory" does need 750MB here. The process which takes the memory is parse-metadata. I assume that this way will become the default way to keep the system up to date for external people, so I consider this issue critical.
This problem of the YUM parser is known and comes from the metadata design (it is necessary to parse all translations of all langauges). What is strange to me, is that there are both formats of metadata in the source (I checked /pub/opensuse/distribution/SL-OSS-stable/inst-source, the above mentioned doesn't exist), there should be only one. AFAIK, it was decided that for the base products, we won't use the YUM metadata. But you are right, the for YUM source for updates, this issue will be critical. Klaus, Michael, any comment?
("WE" won't use the yum metadata, but it's IMO a good idea to provide them.) A) we must know which translations for an item are available (in order to serialize it). B) we must be able to provide any translation for an item on demand (for UI and serialize) C) we don't need to store everyting in memory (but reparsing the xml is not cheap, and we need a more elaborated TranslatedText class for this. i.e. TT enabled to serve as cache, triggering a reload from disk on miss.) If it is just a matter of resolvable metadata stored in the ResObject, we can delay the fix until TT was enhanced. Or do we have the complete documents DOM tree in memory while parsing? This might be an additional penalty. -- I'll take care of TT. Jiri: Within the Yum source impl. we will then need methods, which reload a cetain transated item (label, descr,..) in a specific locale from disk. (exact locale; caching and locale fallback will be handled by TT).
It is also fine, when we use a different repository format be default. Can you recommend another one without the memory problems ?
I guess, this is a duplicate of 157474 But this discussion should't be lost. *** This bug has been marked as a duplicate of 157474 ***