| 1 |
On Sun, 15 Feb 2009 15:56:18 -0800 |
| 2 |
Zac Medico <zmedico@g.o> wrote: |
| 3 |
> If the package manager is not able to validate a cache entry that |
| 4 |
> has been generated for an unsupported EAPI, then it will be forced |
| 5 |
> to regenerate the metadata in order to check whether or not the EAPI |
| 6 |
> has changed (example given 2 emails ago). Don't you agree that it |
| 7 |
> would be useful to be able to avoid metadata generation in cases |
| 8 |
> like this, if possible? |
| 9 |
|
| 10 |
Well... The solution you give only *sometimes* avoids it, so it's only |
| 11 |
worth it if we expect that most EAPI changes won't mess around with |
| 12 |
inheriting at all. And given that we probably want per-cat/pkg |
| 13 |
eclasses... |
| 14 |
|
| 15 |
It only comes into its own if you expect there to be a long time |
| 16 |
between an EAPI being used in the tree and an EAPI being supported by a |
| 17 |
package manager. And even then, it's probably easier to just do a minor |
| 18 |
stable release straight away with rules for "don't know how to use this |
| 19 |
EAPI, but do know how to read metadata cache entries for it" whilst |
| 20 |
keeping new EAPI support for the next major release. |
| 21 |
|
| 22 |
Honestly, I don't think it'll be useful often enough that it's worth |
| 23 |
the added ick. |
| 24 |
|
| 25 |
-- |
| 26 |
Ciaran McCreesh |
Archives