Ximin Luo: > With our current .buildinfo setup, the above process is more > complicated, because we *only* store hashes of the binary build > environment.
I'm sorry but this is not accurate regarding the current specification . It says: Build-Environment List of all packages forming the build environment, their architecture if different from build architecture, and their version. The idea to put a hash of the binary package in the Build-Environment is a late addition to the original idea. It came as a way to make `srebuild` job easier: retrieving a specific binary package with its hash is already part of snapshot.debian.org interface. It also makes unecessary to find the relevant repository snapshot and the related headaches with how to handle expired signatures. In any cases, we currently don't have code to store any hash of the Build-Environment. If we wanted to store hashes of binary packages, then we would need to have them in /var/lib/dpkg/status and it's not done yet, even if Guillem said this would be a good thing to have. > Currently, to run a DDC test, we would have to read the buildinfo > file, find the hashes of the binary build-deps, lookup the source > packages that corresponds to these hashes, find a different binary > build-deps for these hashes, and run our DDC-checker. This takes many > round trips, and contacting external infrastructure that isn't > necessary. You would not need to lookup the source packages using hashes. Using package and version gives you enough info to retrieve a specific source package from the archive. > If .buildinfo files contained source hashes, the DDC-checker could > work more directly, without requiring a remote repository of source > hash <-> binary hash mappings. I'm interested in `.buildinfo` in the context of the Debian project. The Debian archive is designed to be immutable. A specific version of a package will always correspond to the same source and binary files. So I don't see why one would do complex “source hash - binary hash mapping” when you can just rely on what is in the archive (and what has been archived by snapshot.debian.org). If by building thing that ought to match a specific package version you get different result, then you will have to investigate in any cases. Implementation-wise, getting the hash of the .dsc in the .buildinfo is going to be very tricky. dpkg does not know about what's available in the archive. It just knows about packages which are or were installed. : https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification -- Lunar .''`. lu...@debian.org : :Ⓐ : # apt-get install anarchism `. `'` `-
Description: Digital signature
_______________________________________________ Reproducible-builds mailing list Reproduciblefirstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds