Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: "Michał Górny" <mgorny@g.o>
Subject: [gentoo-dev] [PATCH] glep-0075: Update for reference implementation
Date: Thu, 24 Oct 2019 11:51:23
Message-Id: 20191024115048.7408-1-mgorny@gentoo.org
1 Fill in the reference implementation section. Reduce the requirements
2 for cutoffs to support only multiples of 4, as there is no point
3 in making the implementation more complex for something we aren't using
4 anyway. Fix a typo.
5
6 Signed-off-by: Michał Górny <mgorny@g.o>
7 ---
8 glep-0075.rst | 38 +++++++++++++++++++++++++++++---------
9 1 file changed, 29 insertions(+), 9 deletions(-)
10
11 diff --git a/glep-0075.rst b/glep-0075.rst
12 index 31553e7..4586463 100644
13 --- a/glep-0075.rst
14 +++ b/glep-0075.rst
15 @@ -7,8 +7,8 @@ Type: Standards Track
16 Status: Draft
17 Version: 1
18 Created: 2018-01-26
19 -Last-Modified: 2018-12-01
20 -Post-History: 2018-01-27
21 +Last-Modified: 2019-10-24
22 +Post-History: 2018-01-27, 2019-10-24
23 Content-Type: text/x-rst
24 ---
25
26 @@ -100,11 +100,14 @@ and the policies for introducing new hashes are covered by GLEP 59
27 The cutoffs list specifies one or more integers separated by colons
28 (``:``), indicating the number of bits (starting with the most
29 significant bit) of the hash used to form subsequent subdirectory names.
30 -For example, the list of ``2:4`` would indicate that top-level directory
31 -names are formed using 2 most significant bits of the hash (resulting
32 -in 2² = 4 directories), and each of this directories would have
33 -subdirectories formed using the next 4 bits of the hash (resulting
34 -in 2⁴ = 16 subdirectories each).
35 +For example, the list of ``4:8`` would indicate that top-level directory
36 +names are formed using 4 most significant bits of the hash (resulting
37 +in 2⁴ = 16 directories), and each of this directories would have
38 +subdirectories formed using the next 8 bits of the hash (resulting
39 +in 2⁸ = 256 subdirectories each).
40 +
41 +The implementations are only required to support cutoffs being multiples
42 +of 4. Support for other values is optional.
43
44 The exact algorithm for determining the distfile location follows:
45
46 @@ -296,6 +299,16 @@ relatively low complexity and being reasonably future-proof.
47 (x — content checksum, + — filename checksum)
48
49
50 +Cutoff values
51 +-------------
52 +The original draft allowed any cutoff values. This was changed since
53 +multiples of 4 are much easier to implement — they can be trivially cut
54 +from hexadecimal representation of the hash value. This representation
55 +is commonly used by hash function implementations, including the Portage
56 +utility functions, pkgcore utility functions (snakeoil) and ``b2sum``
57 +utility from coreutils.
58 +
59 +
60 Layout file
61 -----------
62 The presence of control file has been suggested in the original
63 @@ -363,7 +376,14 @@ to an appropriate subdirectory.
64
65 Reference Implementation
66 ========================
67 -TODO.
68 +The support for this specification has been implemented in Portage,
69 +as of version 2.3.77. This includes both fetching distfiles,
70 +and maintaining mirrors via ``emirrordist``. The implementation
71 +supports both listed layouts, with all hash functions supported
72 +by Portage and cutoffs being multiples of 4.
73 +
74 +As of 2019-10-18, the Gentoo Infrastructure team has successfully
75 +deployed the ``filename-hash BLAKE2B 8`` layout on Gentoo mirrors.
76
77
78 References
79 @@ -389,7 +409,7 @@ References
80 for each directory computed in a way to have the files distributed evenly'
81 (https://archives.gentoo.org/gentoo-dev/message/611bdaa76be049c1d650e8995748e7b8)
82
83 -.. [#PKGNAME] Jason Zamal's reply including 'using the same dir layout
84 +.. [#PKGNAME] Jason Zaman's reply including 'using the same dir layout
85 as the packages themselves)
86 (https://archives.gentoo.org/gentoo-dev/message/f26ed870c3a6d4ecf69a821723642975)
87
88 --
89 2.23.0

Replies