Alternative forms of metadata

[Anders F Björklund]

Jeff Johnson wrote:

>> Smart is currently using the XML version of Yum's RPM-metadata,
>> the primary/filelists/other (and group) files from createrepo:
>> http://linux.duke.edu/projects/metadata/
>>
>> Other package managers have moved to more "efficient" forms of
>> representing these, and there has been some requests that Smart
>> should read the alternative forms instead of the regular XML:
>>
>> yum sqlite: https://bugs.launchpad.net/smart/+bug/244889
>>
>> zypp .solv: https://bugs.launchpad.net/smart/+bug/251020
>>
>> ...
> The yum:sqlite format is a sqlite database, which is hardly a
> form of markup. The data in the sqlite db is equivalent to the
> XML, and the yum XML is likely (imho) to continue to be generated
> for some time.
>
> What would likely be more useful than adding yum sqlite would
> be to verify the signature on the repo xml, I'm not sure whether
> smart does that yet.

Support for the ***_db sqlite format is sorta already added
(although hackily), so it shouldn't be a major deal to just
include if proven to be useful (presumably by being faster):
http://bazaar.launchpad.net/~afb/smart/sqlite/revision/820

I have added signature checking as a separate Wishlist issue:
https://bugs.launchpad.net/smart/+bug/250941 (as per openSUSE)

> (aside) What yum really needs to do is an incremental, rather than  
> an entire,
> distribution for repo markup.
>
> I was told yesterday by someone at SuSE that the solv format is used
> for internal cache, not for distribution. That may or not be true.  
> It will
> be very tricky to use the binary .solv format outside of a zypp  
> context,
> the format is very specific to zypp with its sat-solver so far. Its  
> too early
> to tell whether .solv is useful (or not).
>
> But SuSE is doing an exceptional job of providing multiple sources
> of repo metadata. Perhaps reading the metalinker data would be more
> useful for smart than chasing .solv files.

OK, maybe mixing solv and sqlite up wasn't such a good thing. :-)

It seems like sqlite *could* make a useful optional feature, although
adding some code and a dependency on one of the python-sqlite modules.
Maybe it could be done in some more clever way than a simple boolean,
so it becomes easier for packagers et al to exclude if not wanted ?

On second glance, it looks like *.solv is not included in repomd.xml.
So it would probably make for a new channel format instead of rpm-md.

--anders