Le lundi 28 mai 2007, Thomas Lotterer a écrit :
> 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.

- yes, there are other, but not always present.

> - It is unique for every (re)build.

- yes

> - Binaries packages carry the PKGID of their source package in SOURCEPKGID

Only if you're using rpm -ba and rpm --rebuild, but doing:

rpm -Uvh .src.rpm
rpmbuild -bb .spec

will break the flow and information will get loosed.

> - This allows checking of genealogy.

I just demonstrate in some case, it don't

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

Yup, because rpm --rebuild does -Uvh, rpmbuild -bb internally but keep a track 
of pkgid.

To avoid this, and allow to trace genealogy in a safer maner, I think to 
SPECMD5 include in both src and binary containing the md5sum of the specfile.
But don't made a mistake, this will only claim "those rpms come from same 
spec", I don't think demonstration are need to recall macros can change lot 
of things.

In sophie, (sophie.zarb.org), to trace genealogy I use these rules:

src PKGID = bin SOURCEPKGIG or
src nvr = bin SOURCERPMTAG

Both are not 100% sure. 

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

The whole specfile is not reasonnable in all binaries, because the size it 
will need, the specfile is probably bigger than the whole header.

But a 16 bytes length binary string is ok, and md5sum is enough to warranty a 
the uniqness of the file in most of case.

WDYT of this idea ?