| 1 |
Mike Kelly wrote: |
| 2 |
> Brian Harring wrote: |
| 3 |
>> One thing I'll note is that the .ebuild-$EAPI approach isn't the end |
| 4 |
>> all fix to versioning extensions that y'all represent it as. |
| 5 |
>> Essentially, what .ebuild-$EAPI allows is additions to version |
| 6 |
>> comparison rules, no subtractions. Each new $EAPI *must* be a |
| 7 |
>> superset of previous $EAPIs. |
| 8 |
> |
| 9 |
> Uhh... no. Just like how older package managers which don't understand |
| 10 |
> how to read the EAPI from a filename suffix would basically ignore the |
| 11 |
> new ebuilds, any package manager that can, but doesn't recognize the |
| 12 |
> eapi of the new one, will just ignore it. It won't ever try to figure |
| 13 |
> out its version or anything, it'll just do nothing. |
| 14 |
> |
| 15 |
> Also, there is absolutely no reason for all future EAPIs to be a |
| 16 |
> superset of old eapis. While paludis (and presumably pkgcore and |
| 17 |
> portage, I'm not as familiar with their code) has implemented EAPI=1 as |
| 18 |
> a few additions to EAPI=0, there is no reason that gentoo might not |
| 19 |
> decide to have EAPI=9000 some day, complete with artificial intelligence |
| 20 |
> that completely obsoletes USE flags, or some such thing (it's late, I |
| 21 |
> know the analogy sucks). |
| 22 |
> |
| 23 |
|
| 24 |
Assuming we won't move from flat file to db |
| 25 |
|
| 26 |
lu - thinking of a darker future. |
| 27 |
|
| 28 |
|
| 29 |
-- |
| 30 |
|
| 31 |
Luca Barbato |
| 32 |
Gentoo Council Member |
| 33 |
Gentoo/linux Gentoo/PPC |
| 34 |
http://dev.gentoo.org/~lu_zero |
| 35 |
|
| 36 |
-- |
| 37 |
gentoo-dev@l.g.o mailing list |
Archives