| 1 |
On Friday 02 September 2005 08:04, Brian Harring wrote: |
| 2 |
> |
| 3 |
> Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi |
| 4 |
> defines revisions of it, in my mind a minor revision of the ebuild 1 |
| 5 |
> format. Any form of loss of backwards compatability *should* be a |
| 6 |
> different format, .ebuild2 for all I care. |
| 7 |
|
| 8 |
The new proposed format loses backwards compatibility. If there is |
| 9 |
backwards compatibility no new format or api version is needed. EAPI |
| 10 |
should work on the python level, not only on the ebuild.sh level. |
| 11 |
|
| 12 |
> Trying to use EAPI to allow for N different formats into one format is |
| 13 |
> wrong from where I sit; you would need a container format for it, |
| 14 |
> which ebuild wasn't designed for (nor is it easily extensible to be |
| 15 |
> made so I posit). |
| 16 |
|
| 17 |
No it would state that the eclass is 100% compatible with both by the |
| 18 |
formats overlapping and the ebuild not threading outside the overlapped |
| 19 |
area. Take for an example many simple kde applications. Those use the kde |
| 20 |
eclass to do all the work and only contain a skeleton of variables |
| 21 |
themselves. These ebuilds are compatible with both the current as the |
| 22 |
proposed new API. When marked so, they could be used as EAPI=1 as soon as |
| 23 |
the kde eclass is ported to EAPI=1. Similarly many eclasses do not |
| 24 |
provide src_compile, and as such are compatible with both EAPI versions. |
| 25 |
|
| 26 |
> EAPI's original specification was for handling addition of new funcs, |
| 27 |
> different hooks in the ebuild; I prefer it remain as this. The core |
| 28 |
> rewrite is format agnostic, if a new format is defined (whether a |
| 29 |
> massively managled version of ebuild or flat out new), it's a seperate |
| 30 |
> format and should be handled via the core, not via ebuild specific |
| 31 |
> package handling. |
| 32 |
|
| 33 |
EAPI now is going to be used for the above. It can however with very |
| 34 |
little effort be made such that future ebuild format revisions are |
| 35 |
possible. Also don't be mistaken that splitting out configure and make |
| 36 |
stages do need support from the python part. |
| 37 |
|
| 38 |
> |
| 39 |
> There's no reason a repository can't hold multiple formats internally; |
| 40 |
> the capability is there, use that rather then trying to jam too much |
| 41 |
> into EAPI, imo at least. |
| 42 |
|
| 43 |
How would you suggest to do this then. The ebuilds/eclasses are completely |
| 44 |
the same except for their EAPI definition. They also have the same |
| 45 |
(file)name. And that is not counting the fact that two files containing |
| 46 |
the same is bad design as there will allways be an issue of one file |
| 47 |
being updated and the other not. |
| 48 |
|
| 49 |
Paul |
| 50 |
|
| 51 |
-- |
| 52 |
Paul de Vrieze |
| 53 |
Gentoo Developer |
| 54 |
Mail: pauldv@g.o |
| 55 |
Homepage: http://www.devrieze.net |
Archives