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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected] mailing list To change your subscription options, visit https://lists.reproducible-builds.org/listinfo/rb-general. To unsubscribe, send an email to [email protected].
