Re: metadata layout problems and some history
"Duncan Mac-Vicar P." <[email protected]> Fri, 13 Aug 2010 14:46:10 +0200
| Newsgroups | gmane.linux.rpm.metadata |
|---|---|
| Message-ID | <[email protected]> |
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