On Fri, Sep 02, 2005 at 08:31:26AM +0200, Marius Mauch wrote: > On 08/27/05 Brian Harring wrote: > > > Hola. > > > > Attached is a patch that > > A) adds EAPI awareness to portage; mainly, if >0, complain and be > > unwilling to merge the package > > Actually I just wrote also a patch for it (for 2.1), however instead of > complaining I just masked them (without unmask ability), just add a > check to gvisible() and getmaskingstatus() (actually just calling > dbapi.eapicheck()). That way it should be more transparent to users IMO. > Won't stop people from using ebuild(1) though. Masking makes a bit more sense, 'cept that information needs to be dumped out when resolution cannot occur.
Further, it's a mild gotcha for users who wonder wth portage is masking a node. Better approach imo though, and would like to see that implemented rather then what I did with the stable patch. Incremental'ing EAPI during inherit is a no go; EAPI1 and EAPI0 are incompatible for execution, due to the src_compile configure/make breakup. Somebody care to split a masking patch for stable rather then the emerge modifications I did btw? I'm poking at ensuring an eapi=0 portage's generated eapi=1 cache entries are not used by an eapi=1 portage without a forced regeneration atm. That and the fact the 2.1 state should be decided, if we're going to have (effectively) two branches of development going at once, vs developmental line and maintenance branch. ~harring
pgprNaO25CXkf.pgp
Description: PGP signature
