-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zac Medico wrote: > Tiziano Müller wrote: >> I'd recommend to prefix the digest with a "{TYPE}" (like for hashed >> passwords) to be able to change the digest algorithm as needed >> (especially in regards to the current SHA successor competition). >> This allows a future package manager which might use SHA-3 for hashing >> (once it's released) to still check old digests. Furthermore it would >> allow for easier transition and only needs a definition of allowed >> hashes instead of a specific one. > > I like that idea. That way it's not necessary to bump the EAPI in > order to change the hash function. So, a typical DIGESTS value might > look like this: > > SHA1 02021be38b a28b191904 3992945426 6ec21b29a3
While thinking about the implementation details, I realized that it would be very useful to give the DIGESTS data a version identifier that is independent of the EAPI. This will allow a package manager to validate a cache entry that has been generated for an unsupported EAPI, and allows it to trust that there's no point in regenerating the cache entry (to see if the EAPI has changed since the last time that it was generated). For example, suppose that we introduce EAPI 3 and a package manager that does not support EAPI 3 encounters a cache entry for an EAPI 3 ebuild. If the package manager recognizes the DIGESTS data version and it's able to validate the cache entry, then it can avoid the cost of regenerating metadata for that ebuild. If the user modifies the ebuild locally to change the EAPI to a supported EAPI (from 3 to 2, for example), the DIGESTS data will allow the package manager to recognize that the cache entry has been invalidated and needs to be regenerated (and it will discover that the EAPI has changed to a supported value). So, if a "0" version identifier at the beginning of the DIGESTS data, a typical entry could look like this: 0 SHA1 02021be38b a28b191904 3992945426 6ec21b29a3 Regardless of what the EAPI value happens to be, the package manager should be able to trust that the version identifier is a reliable indicator of the mechanism which should be used to validate the integrity of the cache entry. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYnFwACgkQ/ejvha5XGaNTzQCdFyZpEBZhftEISVrBBT+DsOHv JXEAn2KtO/g0KjQtQu8fuB8KGF9Krr/d =TxtX -----END PGP SIGNATURE-----