[Rpm-metadata] two other areas needed

Jeff Johnson n3npq at nc.rr.com
Mon Oct 6 16:07:55 UTC 2003


Darrin Thompson wrote:

> seth vidal wrote:
>
>> my general opinion is this last file could be entirely optional, so if
>> it is not present no one should be able to call foul, but it would be
>> nice to define the file format so it could be used in a consistent way,
>> if present.
>>
>
> It's a great idea. But so are a lot of other things.
>
> It seems like the minimum functionality needed is two classes of files.
>
> 1. A single file which has repository wide scope. It points to 
> complete metadata files and is extensible to point to other kinds of 
> files.
>
> 2. A series of metadata files which contain large lists of package 
> metadata. It is extensible to allow including metadata not applicable 
> to most package formats.
>
> You could, for instance, extend the repository wide file to point at 
> metadata "indexes" for the benefit of yum. You could extend it to 
> point at changelogs etc.
>
> These cool things would all be extensions. Clients could ignore 
> extensions they don't understand.
>

Before we start smearing meatadata all over the place, I point to 
alikins original proposal.

He was not suggesting multiple files, only suggesting that there are 
alternatives to a strict
single file representation.

And he also suggested the criteria for splitting metadata into seperate 
files, minimizing bandwidth
by intelligently factoring slowly changing metadata into seperate files 
that can be downloaded
less often using, say, HTTP 1.1 byte ranges.

Adrian is not wrong, but it will take some thought about organising into 
"smarter metadata".

73 de Jeff




More information about the Rpm-metadata mailing list