[repo-coord] Re: Repo information inside rpm?

[Morten Kjeldgaard]

> a serial number in Distribution has its value, I'm sure.  To highlight
> the purpose a little better, it may do well to discuss exactly what
> information is lacking in the current RPM header set that drives this
> standardization.

What is missing in the RPM header is an accurate indication of where the 
RPM came from. My own needs are what I specified on Aug. 13, but I have 
since reconsidered under the influence of others on the list. People 
objected to having static locators present in the RPM file, the way around 
it is having that information in an external and editable form. Axel asked 
for a proposal linking an RPM with an external source of information, and 
as a path to that, a unique ID is needed. That is a simple extension to my 
original proposal, and can be achieved by adding another keyword to the 
*repo* string in the Distribution tag.

> 1. URL can be embedded in Vendor and/or Packager.

No. The URL should point to the home-page of the program in the package.

> 2. Dist should be munged using some well thought out dist tag appended
> to the release.
> 3. Ditto #2 for release.

I don't grok what you mean here?? The point in my original proposal was 
that all the repos are different, but these differences could be handled 
with the same keyword scheme.

> 4. Arch is obtainable here: rpm -q --qf "%{arch}"

No. We are not talking about the RPM architecture, but the Apt/Yum 
architecture, typically part of the path in the sources.list/yum.conf 
files.

> 5. yum can obtain "Repo" for comp, I guess: "yum list rpm". (Apt doesn't
> do this.)

Yes, Yum calls components for "repo" :-(.

> So, I'm just thinking that there needs to be a compelling reason that a
> buildid needs to be created. Most of the above information is existent,
> therefore it'll be hard to gather enough moment behind this effort.

I see this as a first step in creating a more robust system that remedies 
some of the weaknesses of RPM.

> Also, it probably doesn't need to be globally unique (like some guid
> thingy) because the system can infer uniquity among individual
> repositories.

Perhaps it is possible to device a such a scheme, but it would be 
completely silly NOT to have different IDs since it is a trivial task. I 
could write a client/server program in 15 minutes listening to a UDP port 
and answering with a unique ID.

With a unique ID you can stuff all the info in an SQL database, which will 
permit all kinds of sofisticated queries.

> I want to help and I will immediately support any agreed upon standard
> as implemented by the RPM Consortium(tm) ;-).

Yo, man! :-)

/Morten