| 1 |
On Thu, 2019-10-24 at 22:39 +0200, Ulrich Mueller wrote: |
| 2 |
> > > > > > On Thu, 24 Oct 2019, Michał Górny wrote: |
| 3 |
> > +in 2⁴ = 16 directories), and each of this directories would have |
| 4 |
> |
| 5 |
> s/this/these/ (This was there before, but can be corrected while at it.) |
| 6 |
> |
| 7 |
> > +The implementations are only required to support cutoffs being multiples |
| 8 |
> |
| 9 |
> s/The implementations/Implementations/ |
| 10 |
|
| 11 |
Both fixed in place. Since they're grammar fixes, I suppose there's |
| 12 |
no need to send v2 over it. |
| 13 |
|
| 14 |
> |
| 15 |
> > +and maintaining mirrors via ``emirrordist``. The implementation |
| 16 |
> > +supports both listed layouts, with all hash functions supported |
| 17 |
> > +by Portage and cutoffs being multiples of 4. |
| 18 |
> |
| 19 |
> In the rationale section, one reason given for the choice of the hash |
| 20 |
> algorithm (BLAKE2B) was to "avoid code duplication". Isn't that argument |
| 21 |
> moot, if all hashes supported by Portage are implemented? (Or in other |
| 22 |
> words, couldn't a faster hash function like MD5 be used?) |
| 23 |
|
| 24 |
That's a very Portage-centric thinking. Technically, today's PM needs |
| 25 |
only to be implement SHA512 and BLAKE2B. The former is legacy, |
| 26 |
so in the future we will probably throw it away and either leave BLAKE2B |
| 27 |
only, or add another new hash. In either case, BLAKE2B is the most |
| 28 |
future-proof choice today. |
| 29 |
|
| 30 |
-- |
| 31 |
Best regards, |
| 32 |
Michał Górny |
Archives