On Friday 02 September 2005 08:04, Brian Harring wrote: > > Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi > defines revisions of it, in my mind a minor revision of the ebuild 1 > format. Any form of loss of backwards compatability *should* be a > different format, .ebuild2 for all I care.
The new proposed format loses backwards compatibility. If there is backwards compatibility no new format or api version is needed. EAPI should work on the python level, not only on the ebuild.sh level. > Trying to use EAPI to allow for N different formats into one format is > wrong from where I sit; you would need a container format for it, > which ebuild wasn't designed for (nor is it easily extensible to be > made so I posit). No it would state that the eclass is 100% compatible with both by the formats overlapping and the ebuild not threading outside the overlapped area. Take for an example many simple kde applications. Those use the kde eclass to do all the work and only contain a skeleton of variables themselves. These ebuilds are compatible with both the current as the proposed new API. When marked so, they could be used as EAPI=1 as soon as the kde eclass is ported to EAPI=1. Similarly many eclasses do not provide src_compile, and as such are compatible with both EAPI versions. > EAPI's original specification was for handling addition of new funcs, > different hooks in the ebuild; I prefer it remain as this. The core > rewrite is format agnostic, if a new format is defined (whether a > massively managled version of ebuild or flat out new), it's a seperate > format and should be handled via the core, not via ebuild specific > package handling. EAPI now is going to be used for the above. It can however with very little effort be made such that future ebuild format revisions are possible. Also don't be mistaken that splitting out configure and make stages do need support from the python part. > > There's no reason a repository can't hold multiple formats internally; > the capability is there, use that rather then trying to jam too much > into EAPI, imo at least. How would you suggest to do this then. The ebuilds/eclasses are completely the same except for their EAPI definition. They also have the same (file)name. And that is not counting the fact that two files containing the same is bad design as there will allways be an issue of one file being updated and the other not. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpvjqA2Lzlsg.pgp
Description: PGP signature
