Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation

[Zac Medico <zmedico@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 15 Feb 2009 15:56:18 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
>> 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?
> 
> Well... The solution you give only *sometimes* avoids it, so it's only
> worth it if we expect that most EAPI changes won't mess around with
> inheriting at all. And given that we probably want per-cat/pkg
> eclasses...

Well, I think it's more like "the vast majority of the time" than
just "sometimes", and it's a lot better than "never".

> It only comes into its own if you expect there to be a long time
> between an EAPI being used in the tree and an EAPI being supported by a
> package manager. And even then, it's probably easier to just do a minor
> stable release straight away with rules for "don't know how to use this
> EAPI, but do know how to read metadata cache entries for it" whilst
> keeping new EAPI support for the next major release.

But how will it know if it supports those cache entries? Wouldn't
the easiest way to determine that be to have a DIGESTS version
identifier? Otherwise, the only way for it to know would be to parse
it and either throw a parse error if necessary or proceed all the
way to the digest verification step (if it doesn't hit a parse error
first).

> Honestly, I don't think it'll be useful often enough that it's worth
> the added ick.

Doesn't a simple version identifier seem less icky than checking for
both a parse error and digest verification failure?
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmYt+oACgkQ/ejvha5XGaOC6gCgzgIcH6D7X/o/vOuWvsS0mp42
dGsAn17xnY8bX9IG28Uj3MX42qdrxGrL
=+Hkp
-----END PGP SIGNATURE-----