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)'

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.

> 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.

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. 

-- 
http://thomas.lotterer.net