[rb-general] Regarding "Zero Install" manifests

[Anders Björklund]

Holger Levsen wrote:
>> Looking at https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles
>> it seemed rather specific to Debian and I didn't see any contents ?
>>
>> The idea was for a single format that would describe the binaries.
>> Wouldn't hurt if it was something like how git describes the code ?
> 
> you're right, so far we only really "have" .buildinfo files for Debian,
> where "have" means having a documented format, which has a tested 
> implementation and has been proven to work for user to reproduce
> specific builds.
> 
> Or maybe *I* only know about those Debian .buildinfo files… ;-)

I'm mostly used to RPM, but I suppose the format _could_ be adopted...

> And then, .buildinfo files is both a specific implementation for Debian,
> as well as a general concept, which might be called differently and
> *structured* differently. This is mostly because we think that different
> projects will want to use those formats which are natural to them
> (eg rfc822 for Debian).
> 
> Sometimes projects already have files which describe build results, and
> those files already have a name… there we rather want to add missing
> information to these files, so they can be used for reproducing binaries.

Actually I was only talking about the payload, but this is interesting.


> Does this make more sense now? I wish we had this documented more
> clearer on https://reproducible-builds.org/docs/ and would love to hear
> feedback from you how to achieve that! :-)
> 
> some more (rough) notes are available at
> https://reproducible-builds.org/events/berlin2016/buildinfofiles/

Thanks, found some more notes at:
https://reproducible-builds.org/events/berlin2016/RPM/
https://reproducible-builds.org/events/berlin2016/RPMII/


Anyway, the basic idea seems to be the same as in the rpm metadata.
That is, to take the checksum of the *container* after compression:

Format: 0.2
Source: zlib
Binary: zlib1g zlib1g-dev zlib1g-dbg zlib1g-udeb lib64z1 lib64z1-dev
lib32z1 lib32z1-dev libn32z1 libn32z1-dev
Architecture: amd64
Version: 1:1.2.8.dfsg-5
Checksums-Md5:
 0b0838dfff297b7230215b0401e791df 87522 zlib1g_1.2.8.dfsg-5_amd64.deb
Checksums-Sha1:
  fa253be7e1e0237df506c7687da98215aab716fe 87522
zlib1g_1.2.8.dfsg-5_amd64.deb
Checksums-Sha256:
 b5fe79041db0a5ed4c8297f7c1c2ec0c344be6eea0a7d0977a0f2a1dceea2ff3 87522
zlib1g_1.2.8.dfsg-5_amd64.deb

<package type="rpm">
  <name>zlib</name>
  <arch>x86_64</arch>
  <version epoch="0" ver="1.2.7" rel="17.el7"/>
  <checksum type="sha256"
pkgid="YES">fabb4fa66389272d4dde7a4e0e6369da64563c14dada2493a44002e8a6d2f3c2</checksum>

So you will get different checksums, depending on the transport
mechanism (pkg format) and also for different compression formats.


And you'll still need to unpack and run diff, to know the difference ?
This is very different, from having a checksum on the actual content...

If we recorded the checksum of the output, you could just compare that.
Either even *before* downloading, or after downloading and extracting.

Something small like "sha1new=71dee7bfa1b3df0cd959aae2d241848cc37bffb4"
or "sha256new_CUET5FU2IXYEWGIIPTR5QLZ35KHIQ6KVUONZZG4SIQSXXOKBIKUQ" ?

It's just the checksum of the checksums, after recursion and sorting.
Where the format uses Base32 to avoid that linebreaking seen above...

/Anders