Hi! Guillem Jover: > I've been thinking about this, and I think you might be trying to > solve the problem in the wrong place(s), and possibly there's a need > to step back and ponder about what do you really want out of all this, > to know where or how to best fix it. > […]
My ideal scenario is the following: 1. I retrieve the .changes file for a package. 2. I verify the signature on the .changes. 3. I give the .changes to a "rebuild" tool. 4. The checksum of the .deb listed in the original .changes file and the checksum of the .deb I've just built should match. I even would like to compare the rebuilt .deb not only by one source, but by several. I would rather avoid to have a `dpkg-deb --compare` as you suggested because comparing signed checksums is much easier that to transfer `.deb` all around between multiple independent builders. > And then there's changing information that conveys important data. > For example, in the generated data.tar the files will contain > different modification times, some will come untouched from the source > files if they just get copied, and others will be newer if the files > got created at build time. Preserving these timestamps seems important > to me, because you then know the possible staleness of the files. I disagree that this is important information. Most packages that I have seen so far do not propagate timestamps when copying a file from source. Could you give me an example of one that would do so? If you are set on this, then our only solution is to generalize the use of faketime. I found this more clumsy but we already encourage using fakeroot… > The timestamp on the ar member let's you know when the package got > built. I don't believe this add much value: we have this information in the .changes files already. Anyway, I was thinking of adding a `--timestamp=1377619307` option to `dpkg-deb`. The value would default to `time(NULL)` when the flag is missing. This could allow the rebuild tool to extract the timestamp from the .changes file in order to match the initial build. But this has extra complications given that different calls to dpkg-deb and dpkg-genchange will have different timestamps at the moment. > Possible future ar members containing gpg signatures from the builder > or the archive, would change and not be reproducible anyway. The recent > switch of dpkg-deb default compressor. Or possible future .deb format > revisions. Etc. Could you please elaborate? The idea is to record list of packages that has been initially able to build the package and to reinstall exactly the same set of packages (from snapshot.d.o) when performing rebuilds. I don't really understand how future changes in dpkg would affect any earlier versions that would get reinstalled to do the rebuild. -- Lunar .''`. lu...@debian.org : :Ⓐ : # apt-get install anarchism `. `'` `-
signature.asc
Description: Digital signature