On Mon, Aug 02, 2010 at 11:55:07PM +0200, Matti Bickel wrote: > On 08/02/2010 10:15 PM, Ciaran McCreesh wrote: > > Aren't you really after per-package eclasses, not elibs? > > Yes. I don't care whether the snippets may affect metadata. They already > don't (at one time they did, but we got warned that that's illegal - > that's why php-5.3 ebuilds have their metadata folded back into them). > > >> Instead of all the backwards-compatibility issues the GLEP deals with, > >> we could just sneak the implementation into EAPI4 and be done with it. > > > > No, you can't make global scope changes just in an EAPI without > > screwing up user systems. You have to do the whole "wait several years" > > thing for them.
While it's been repeated many, many time, this statement is provably false. What _is_ true is that you cannot have new global scope functionality that influences/sets EAPI. That is _accurate_ truth of the matter. If a PM encounters an EAPI it doesn't understand/support, by definition the metadata it tried generating is not usable- the PM doesn't support that new EAPI thus it has zero clue how to generate/store metadata appropriately for that EAPI. Note that since policy forbids EAPI being set in eclasses _anyways_, there isn't a conflict here despite ciaran's claims. If an EAPI adds a new global function that cannot set/influence EAPI, PM's that don't support that EAPI will spit complaints about 'missing command' during sourcing- however the PM will still see the EAPI value is one it knows it doesn't support, and act accordingly. Basically, the only real issue here is that PMs invalidly output stdout/stderr for EAPIs they don't support- this gives the perception that there is an issue, when in reality it's just the PM being slightly user unfriendly. > Bad. So I guess it's back to ferring's "use a new directory not readable > by old PMs" idea. GLEP55++, but having to wait several months for that > and GLEP33 *on top* is not very motivation for me. The reason for a new directory was to enforce a new structuring that was more friendly to changelogs and manifests- due to ECLASSDIR being documented in PMS (and annoyingly eclass-manpagers being the sole consumer of it) adding a new eclasses directory should require a EAPI bump. As for per package eclasses, I'd personally require accessing the package eclass being done via a new inherit function- this avoids some annoying gotchas. That said, I don't see a reason right now that it couldn't be added into an EAPI, per the reasons I laid out earlier in this email. ~brian
pgpIa4DAqHM6U.pgp
Description: PGP signature
