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 |