[rb-general] rb formalism

[Bernhard M. Wiedemann]

On 18/12/2018 11.48, Eric Myhre wrote:

> I think it's quite nice to see 'h(■)' as a git commit hash or say an
> IPFS content hash or other precise value rather than a potentially
> ambiguous human-labelled version string... 👼
> 
> (I was toying with using the '□' sigil to describe such a human-readable
> label which has yet to be resolved into a concrete 'h(■)' value, but
> that got a lot more opinionated, so, hard to write up here.)

Yes, indeed.
In the reproducible builds context, I was thinking of □
as a vague description of required inputs,
e.g. in our krita.spec file we have

BuildRequires:  zlib-devel
BuildRequires:  pkgconfig(Qt5Concurrent)
BuildRequires:  pkgconfig(Qt5Core) >= 5.6

and then comes our build resolver to find concrete binary inputs
matching ("providing") those and bringing in binary packages:
zlib-devel-1.2.11-5.1
libQt5Core-devel-5.11.2-1.1
libQt5Concurrent-devel-5.11.2-1.1

h(■) here would not just be the hash of these version strings, but the
hash of the actual binary input rpm artifacts. This is required, because
(in the general case) we can have multiple parallel repos involved in
one build, with binaries with identical version numbers, but different
content.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20181218/ade37132/attachment.sig>