On May 28, 2007, at 5:06 PM, Thomas Lotterer wrote:

> n3npq@mac.com wrote on 2007-05-28 09:45:
>> Running a look-aside cache of SRPM headers, each of which is named  
>> by its
>> SRPM pkgid, solves the original request in principle. Each binary  
>> package
>> carries the SRPM pkgid from which it was built, and that pkgid can  
>> be used as
>> a retrieval key on the look aside cache.
>>
> Well, almost. Digging out research I did one year ago, my results  
> were:
>
> - The PKGID is a unique package identifier.
> - It is unique for every (re)build.
> - Binaries packages carry the PKGID of their source package in  
> SOURCEPKGID
> - This allows checking of genealogy.
> - If binary package was build directly from SPEC then  
> SOURCEPKGID='(none)'
>

Number 4 is true if no src.rpm was produced. There's a bugzilla bug  
from Russ Herrold
on exactly this issue. I can devise means to carry forward a pre- 
existing SRPM
Pkgid if necessary, but currently my answer is
    No SRPM == no RPMTAG_SOURCEPKGID, duh

> The last item needs some attention in practice as it breaks  
> genealogy.  I
> understand that this is effect is natural for "rpm -bb" but at  
> least for "rpm
> -ba" it should have been possible to put the PKGID of the generated  
> SRPM into
> the sibling binary RPM.
>

(hysterical aside) The RPMTAG_COOKIE was originally designed for your
genealogy. The intent was to permit user rebuilds, but tie an identifier
back to the distro SRPM. I can likely dust off these code paths and  
do whatever
you want, there is no current active use of RPMTAG_COOKIE that I'm  
aware of.

>> OK, I better understand what you want now.
>> A build process goes through stages, each of which has inputs and  
>> outputs.
>> [lengthy description of impossibility to fully track everything]
>>
> Sure it is not possible to track everything inside and outside the  
> build
> environment.  So my vision of reproducibility is clearly finite. I  
> want
> packaging to carry it's own packaging information forward. That  
> means the spec
> infos should go into SRPM and finally end up in binary RPMs. Every  
> stage adds
> some more information. Only in rare cases should information be  
> lost, one valid
> example might be dropping the tarballs between SRPM->RPM stage.
>

I dinna mean to patronize, just to clarify what you want by asking in  
a different
vocabulary.

> Being egositic, my biggest headaches over the years were the lost  
> BuildPreReqs.
> I have to admit that some years ago I tried following the code path  
> within RPM
> to understand why and where this information gets lost but I  
> failed. It seems
> to me that the internal logic initially knew PreReq only and some  
> weird stuff
> was added later to support BuildPreReq but reusing the existing  
> logic including
> the variables. Anyway, if this information would make it through  
> the end of the
> chain, it would help me removing some dirty workarounds in related  
> utilities.
>

Welcome to my rpm puzzle palace! (that's called self effacing irony  
just in case ;-)

Build dependencies are exactly identical to package dependencies, the  
only
difference is that they are carried in a srpm, not a binary rpm.  
There is also
no difference (since RHL 6.2) in a BuildPreReq: and a BuildRequire:,  
so I
will use (and interpret) either usage interchangeably.

The build dependencies are used in exactly one place, in the split  
between parsing
a spec file and driving the build itself. A srpm header is added to a  
transaction and
rpmtsCheck() is called to verify that all dependencies are met before  
starting a build.

I'm personally amazed that build dependencies work as well as they  
do. An alternative
implementation might have entirely orthogonal build and install  
dependency trees.
The fact that build dependencies are just level 0 relations in a  
depsolver recursion
astonishes me.

If you can point me at your dirty workarounds, I might be able to  
devise means to
carry the information in headers. Looking at dirty workarounds is  
perhaps easier,
as discussing dependencies and rpm and such often gets abstract and  
confusing
in a hurry.

I always prefer attempting an implementation, mostly because that's  
the way my
head works. I can't get a complete picture of a problem until I see  
the concrete
details that need to be dealt with.

73 de Jeff