| 1 |
On Sun, 15 Feb 2009 16:48:44 -0800 |
| 2 |
Zac Medico <zmedico@g.o> wrote: |
| 3 |
> > It only comes into its own if you expect there to be a long time |
| 4 |
> > between an EAPI being used in the tree and an EAPI being supported |
| 5 |
> > by a package manager. And even then, it's probably easier to just |
| 6 |
> > do a minor stable release straight away with rules for "don't know |
| 7 |
> > how to use this EAPI, but do know how to read metadata cache |
| 8 |
> > entries for it" whilst keeping new EAPI support for the next major |
| 9 |
> > release. |
| 10 |
> |
| 11 |
> But how will it know if it supports those cache entries? Wouldn't |
| 12 |
> the easiest way to determine that be to have a DIGESTS version |
| 13 |
> identifier? Otherwise, the only way for it to know would be to parse |
| 14 |
> it and either throw a parse error if necessary or proceed all the |
| 15 |
> way to the digest verification step (if it doesn't hit a parse error |
| 16 |
> first). |
| 17 |
|
| 18 |
You just need to give your package manager a way of dealing with EAPIs |
| 19 |
where it can verify that DIGESTS is correct, but not make use of the |
| 20 |
ebuild in question beyond that. Rather than having supported and |
| 21 |
unsupported EAPIs, have supported, partially-understood and unsupported |
| 22 |
EAPIs. |
| 23 |
|
| 24 |
-- |
| 25 |
Ciaran McCreesh |
Archives