On Sat, Mar 03, 2007 at 01:46:56PM +0000, Ciaran McCreesh wrote: > On Sat, 03 Mar 2007 11:51:27 +0100 Simon Stelling <[EMAIL PROTECTED]> > wrote: > > Ciaran McCreesh wrote: > > > I'd like it spelt out please. > > > > Here we go: > > > > > So why not start by imposing deadlines upon more important projects > > > like Portage USE deps, [snip] > > > > USE deps can't be used anyway in EAPI=0 because it would break > > current versions of portage. So we need EAPI=1, but you can't say > > putting together version 2 of a spec before version 1 was writte is > > sane. So we need the EAPI=0 spec. Makes it pretty easy to figure out > > why this spec is fairly important. > > I disagree. It's very easy and probably the best way of doing things to > say "If ebuilds want to use slot deps, use deps or blah, they set > EAPI=1. Otherwise, continue as normal.". So far as I'm aware, > everything currently planned for EAPI 1 is an extension, not a change > in behaviour.
Fair bit more was on the table as potentials for EAPI1; breaking src_compile into src_configure/src_compile, glep33 (eclass2 seperation), misc reductions of env vars and tightening of various metadata (RESTRICT for example, formally forbiding the no* form). Thats off the top of the head, and just the stuff I've had on hold for EAPI=1. Would expect user/group management (glep27 off the top of the head) would be on the radar also, although thats firmly in pioto's court. Either way, when the angle of "do EAPI=1 while waiting for EAPI=0 to be fully defined" was brought up, a vocal subgroup of people initially shot it down. ~harring
pgpzYPBqBrUFC.pgp
Description: PGP signature
