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
