Re: metadata layout problems and some history
Panu Matilainen <[email protected]> Thu, 12 Aug 2010 13:39:06 +0300 (EEST)
| Newsgroups | gmane.linux.rpm.metadata |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 9 Aug 2010, seth vidal wrote: > On Mon, 2010-08-09 at 00:00 +0200, Anders F Björklund wrote: >> seth vidal wrote: >> >> > There have been some small changes over the years but I believe none >> > that have broken the parsers of any of tools. >> >> The biggest changes for smart was the change to the sha256 checksums >> and unique-md-filenames which meant old cache files weren't deleted. >> >> > Then what happened was all of the folks using/maintaining the tools >> > found issues they had to work around and so we did: >> >> > - Smart runs an indexer over the xml files to generate the byte-offset >> > locations of pkgs in the xml file so it can seek to those locations >> > quickly. >> >> Except that quick-er doesn't mean that it still wasn't dog slow... >> >> "Well, at least having an index cuts list time from >> 30 minutes to 30 seconds. On the other hand, that is >> still ridiculously slow compared to the usual 3... >> So I don't think the cache size/startup time matters ?" >> >> So neither metadata nor sqlite has been merged into the trunk. >> It's all being stored in the cache, instead of using XML/SQL. >> > > So help me understand what would make your situation better? What would > make the rpm-md less problematic for smart? AFAICT smart, zypp an apt all would just want a raw dump of the relevant data in a format that's lightweight to read in once to generate their own native data, and at least in case of smart and apt, can be indexed (eg jump to file offset X to access the details that aren't included in the package cache). Yes, dejavu on yum-metadata-parser, which was the yum equivalent of "internal cache creation", only the sqlite format it creates got added (as an extension) to repomd. XML works fine for the raw dump part, except that it's hideously bloated format for what it's used for and expensive to parse (dejavu yum-metadata-parser again), and isn't good for indexing or searching. Heck, a dumb tagged plain-text file would be much better suited for apt (and I assume smart). I've vague memories of Suse actually having such a format at some point before switching to repodata. - Panu -