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

[Jeff Pitman]

On Monday 16 August 2004 20:22, Morten Kjeldgaard wrote:
> But I would like to delay the discussion of what properties are
> mapped, and how it is implemented, until the basics are in place. So
> can we agree to put a unique serial id in the Dist. tag?? Then the
> next discussion can focus on how to acquire the unique id's. And the
> third discussion can hilight what kind of information we wish to
> stash away.

I'm not sure I dig the way this is going.  I prefer knowing what the 
purpose for something is prior to designing it into existence.  Putting 
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.

Your example from above states:
On Friday 13 August 2004 23:59, Morten Kjeldgaard wrote:
> (1) put this in your .rpmmacros file (one line):
>
> %distribution *url=%{repo} dist=%{dist} rel=%{rel} lang=%{?lang}
> arch=%{arch} comp=%{comp}*
>
> (2) in the beginning of each .spec file, put something like the
> following:
>
> #----------------------------------
> %define repo http://blablabla
> %define dist fedora
> %define rel 1
> %define arch i386
> %define comp testing
> #----------------------------------

1. URL can be embedded in Vendor and/or Packager.
2. Dist should be munged using some well thought out dist tag appended 
to the release.
3. Ditto #2 for release.
4. Arch is obtainable here: rpm -q --qf "%{arch}"
5. yum can obtain "Repo" for comp, I guess: "yum list rpm". (Apt doesn't 
do this.)

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.

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

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

take care,
-- 
-jeff