On Fri, 21 Dec 2007 12:15:10 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > I think we should first decide on how EAPI works.
That was decided a long time ago. > Just because we need a new feature, then we produce a new EAPI? > I think that is not feasible, and will confuse developers. Uh... Yes. It's entirely feasible, it's how things work and it's an entirely sensible model. The *problem* is not EAPI itself. The problem is how EAPI is currently specified by ebuilds. That's all the GLEP changes, and all it really needs to change. > >> especially PM specific EAPI. We can't have PM specific EAPI, > >> otherwise we are risking forking/splitting ourself. > > > > Package manager EAPIs don't belong in the main tree, but they have > > uses outside of it. > > Then would you please introduce how paludis-1 EAPI differs from > official EAPI's? It has a bunch of arbitrary, randomly changing features that I need when doing test cases for functionality that isn't covered by any official EAPI. For example, a long before EAPI 1 came along, Paludis had slot dep support. In order to test slot deps, we needed an EAPI that permitted them -- hence paludis-1. -- Ciaran McCreesh
signature.asc
Description: PGP signature
