[Rpm-metadata] metadata layout problems and some history

Duncan Mac-Vicar P. dmacvicar at suse.de
Fri Aug 13 12:46:10 UTC 2010


  On 08/12/2010 02:15 PM, seth vidal wrote:
> Yes, that was my point in starting this discussion.
>
> But what I've been hearing so far is "don't change anything, just let it
> be".
>
> -sv

No way. I fully support creating a better format.

I only oppose using a specific implementation as the "standard" because 
it makes one tool life easier. Panu described the situation very well.

For example, even if for ZYpp searching is not an issue (as all our 
search is implemented on top of the solv attributes API, which provides 
query, and it is fast enough), I fully support a metadata format that 
allows easier searching. (old SUSE format had offsets for package 
descriptions for example, so they culd go and grab them direclty from 
disk at runtime).

My point is. A standard should have as a goal to make every tool life 
good enough. At the same time, make the rpm world interoperable (I am 
pretty sure we have *SUSE users using yum), while still allowing for 
innovation and tool-specific techniques (satsolver/solv files in our case).

Having something "common" means more work too. It means you can't just 
add a tag or name something without asking for some input about how it 
would affect other tools. But I see as an investment. (example: I am 
pretty sure if a more "standard" model for rpmmd would have been in 
place, the "sha" tag would have been named "sha1" and the pkgid=YES tag 
would not had been agreed upon)

At the same time, standards add bloat and reduce agility, so it is 
important to allow for extensions. We have one extension file for repo 
information (repomd.xml) and another for package data (primary.xml). We 
add unofficial tags there, and do not move them unless agreement has 
been made. Until now, only example is the tags information and the 
expiration of metadata. But a place for incubation allows to quickly try 
new concepts before those long discussions about naming and how to solve 
a problem, end.

Duncan



More information about the Rpm-metadata mailing list