-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 15 Feb 2009 15:26:44 -0800 > Zac Medico <zmed...@gentoo.org> wrote: >>>> 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. >>> Validate it against what? If EAPI is unsupported, the package >>> manager can't make use of INHERITED to see what DIGESTS means. >> In the example given, the DIGESTS version identifier would serve to >> indicate that the INHERITED field behaves as required by the >> validation mechanism (regardless of EAPI). If INHERITED can no >> longer be used like that in a new EAPI, the DIGESTS format/version >> will have to be bumped. > > So in effect we're introducing a second level of versioned > compatibility testing? Strikes me as excessive, especially since it > only works for EAPIs where the scope of changes is small enough to > keep the meaning of INHERITED and DIGESTS the same...
If the package manager is not able to validate a cache entry that has been generated for an unsupported EAPI, then it will be forced to regenerate the metadata in order to check whether or not the EAPI has changed (example given 2 emails ago). Don't you agree that it would be useful to be able to avoid metadata generation in cases like this, if possible? - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYq6EACgkQ/ejvha5XGaNumwCeIqaACk67tlvtQNBppUsuOknN 8agAoN8ZuPYQ5KiFMJj/5syG2/mNqgaE =zffn -----END PGP SIGNATURE-----
